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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to a system for 
facilitating the distribution of electronic nioney. In partic- 
ular, the system utilizes tamper-proof electronic units, 
referred to as trusted agents', in combination with nrK>n- 
ey modules to create a secure transaction environment 
in which customers may purchase or sell electronic 
money from merchants using credit or debit card cre- 
dentials. 

Background of the Invention 

[0002] Numerous electronic payment systems are 
currently being developed to accommodate the growth 
in electronic commerce. One method of electronic pay- 
ment is described in patent applications WO-A- 
93/10503. WO-A-95/30211 (Publication date: 09.11.95) 
and WO-A-96/33476 (Publication date: 24.10.96). 
These applications disclose an electronic monetary sys- 
tem for implementing electronic money payments as an 
altemative medium of exchange to cash, checks, credit 
cards, debit cards, and electronic funds transfers. In par- 
ticular, the described system uses money modules 
packaged in tamper-proof housings to store and transfer 
electronic notes. Money module payments may be ei- 
ther real-time, off-line payments between money mod- 
ules (e.g., between a money module contained within a 
customer's "electronic wallef and a nrKxiey module con- 
tained within a merchant's point-of-sale terminal), or on- 
line payments for network services such as information 
retrieval and telephone calls, or for purchasing airline 
tickets, theater tickets, etc. 

[0003] The trusted agents discussed herein are fully 
described in WO-A-95/30211. That application de- 
scribes a system for enabling the secure delivery of 
electronic mercharrdtse with real-time anonymous pay- 
ment or authorizatton-based payment The system al- 
lows both the customer and merchant to feel secure that 
their interests are being served 
[0004] Cash is widely available from banks arKi mer- 
chants. Electronic nrKNney, just like cash, needs to be 
wkiety avaitable in order to gain general acceptance. 
The present invention describes how trusted agents can 
facilitate the distribution of electronic money through 
merchants which are connected to a payment authori- 
zation network. This distributkvi transactk)n can be ac- 
complished kx:ally or remotely from the merchant, 
greatly increasing the distribution points beyorKi the 
banking network. Also, the disctosed distribution system 
can exchange one rrtonetary unit for arKSlher. For exarrv- 
ple, one could obtain U.S. dollars from a British pound 
account. 

[00(^ My electronic monetary system applicatk>n 
WO-A-93/1 0503 disclosed how cash can be exchanged 
for electronic money and vtc&versa. Such a transacton 
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was accomplished locally at a bank teller or ATM ma- 
chine since cash was dispensed. Electronic money 
couki also be dispensed locally rf an ATM or point of sale 
terminal is modified to dispense the electronic money 
s and the terminal could guarantee the security of the 
transactbn. The present invention describes how elec- 
tronic money can be processed remotely and securely 
from a merchant without a special terminal such as an 
ATM or POS terminal. For the customer, the security of 
the transaction is assured by the use of a trusted agent. 
There is no need for special terminals, which unbe- 
known to the customer, could have Trojan horse proc- 
esses which take the customer's electronic rrK>ney or 
capture his secret bank access infomnatkxi. 

Summary of the Invention 

[0006] It is an object of the present invention to pro- 
vkie a secure system using trusted agents for the distri- 
butk>n of electronic money through merchants or banks 
connected to a payment authorization network. 
[0007] It is a further object of the present invention to 
provide a system for buying or selling electronic money 
remotely and securely from a merchant without a special 
terminal. 

[0008] It is yet a further object of the present invention 
to provkie a system that allows a merchant to satisfy a 
customer's need for electronic money even if the mer- 
chant does not have electronic money initially in his pos- 
sessk>n. 

[0009] It is yet a further object of the invention to in- 
crease the distributkxi of electronic money without the 
need to sign-up numerous banks to participate in the 
electronic nnonetary system. 

[001 0] In the present invention, a system for the open 
distribution of electronic money is provkied having a 
customer trusted agent, a first money module associat- 
ed with the customer trusted agent and with which it se- 
curely communicates, a merchant trusted agent that es- 
tablishes a first cryptographically secure sessbn with 
the customer trusted agent, and a second money mod- 
ule associated with the merchant trusted agent with 
which it securely communicates. The first and second 
money modules establish a secorKi cryptographically 
secure session. The customer trusted agent provkJes 
electronic money purchase infomnation and an account 
credential to the merchant trusted agent, and the mer- 
chant trusted agent provkies a receipt ticket to said cus- 
tomer trusted agent. The merchant trusted agent ac- 
cesses an authorization network and initiates an author- 
ization process using information from the electronic 
money purchase informatkxi and the account creden- 
tial. Upon receiving authorizatkx), the merchant trusted 
agent initiates a transfer of electrons nrxxiey from the 
second money rrxxiule to the first nrroney module. 
[0011] In the event the merchant trusted agent does 
not have sufficient funds in its associated money mod- 
ule. Ft attempts to acquire electronk: money from affiliat- 
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ed transaction devices or by withdrawing electronic 
money from a bank at which the merchant has an ac- 
count and which is an electronic money provider. The 
described system architecture and protocols also sup- 
port the sale of electronic money by the customer to the 
merchant, which is analogous to a deposit transaction. 

Description of the Drawings 

[0012] The invention will be described in greater detail 
below with reference to the attached drawings, of which: 
[0013] Figure 1 is a diagram showing the trusted 
agent/nrK)ney module interaction, 
[0014] Figure 2 illustrates the sections and fields of 
various tickets. 

[0015] Figure 3 illustrates the components of a trans- 
action device. 

[0016] Figures 4A-4D illustrate the functional compo- 
nents of trusted agents. 

[0017] Figure 5 is a diagram showing the network 
structure for open distribution of electronic nrwney. 
[0018] Figure 6A Illustrates a Commit protocol. 
[0019] Figure 6B Illustrates an Abort protocol. 
[0020] Figures 7A-7G illustrate an Authorization- 
Based Purchase/Sale of Electronic Money protocol. 
[0021] Figures 8A-8E illustrate an Establish Session 
protocol. 

[0022] Figure 9 illustrates a SerKJ Message protocol. 
[0023] Figure 1 0 illustrates a Check Credential proto- 
col. 

[0024] Figure 11 illustrates an Abort Transaction pro- 
tocol. 

[0025] Figures 12A-12E illustrate a Money Module 
Payment protocol. 

[0026] Figure 1 3 shows the varkMJs message encryp- 
tion layers established among trusted agents and mon- 
ey nrxxiules. 

[0027] Figures 14A-14E illustrate an Establish Ses- 
sion protocol for money modules. 
[0028] Figure 15 illustrates a Send Routed Message 
protocol. 

[0029] Figure 16 illustrates a Send MM/TA Message 
protocol. 

[0030] Figure 17 illustrates a Send TA/MM Message 
protocol. 

[0031] Figures 18A-18B illustrate an Abort Transac- 
tion protocol for nrxxiey modules. 
[0032] Figure 19 illustrates a Send E-Routed Mes- 
sage protocol. 

[0033] Figures 20A-20B illustrate a Transfer Notes 
protocol. 

[0034] Figure 21 illustrates a Commit protocol for 
money nrxxJules. 

Descriptkxi of the Preferred Embodiment 

[0035] As described in WO-A-95/30211 . a trusted 
agent is a combination of hardware and software com- 



ponents. It is tamper-proof and contains secure proto- 
cols which cooperate with a money module to synchro- 
nize secure payment to delivery. Money modules are 
tamper-proof devices capable of storing and transfer- 

5 ring electronic money The electronic money is prefera- 
bly in the form of electronic notes that are representa- 
tions of currency or credit. Money modules are also ca- 
pable of establishing cryptographically secure commu- 
nication sessions with other devices. The preferred em- 

10 bodiment of the present invention utilizes the transac- 
tion money modules described in WO-A-93/1O503 and 
WO-A-96/33476. 

[0036] The trusted agents when making purchases 
over a network, exchange electronic merchandise and 

15 payment. In the present invention, as shown in Figure 
1 , the merchant's trusted agent 4 (MTA) sends a receipt 
ticket to the customer's trusted agent 2 (CTA) . In return, 
the customer's money module 6 sends electronic money 
to the merchant's money module 6 via CTA 2 and MTA 

20 4 when the customer is selling electronic money. If the 
customer is purchasing electronic money, then the elec- 
tronic money flows from the merchant to the customer. 

Tickets 

25 

[0037] Refen-ing to Figures 1 and 2, a ticket 8 is an 
electronic item created by a MTA 4 and transferred to a 
CTA 2 during a transactk>n. Tickets may be thought of 
as the property of the trusted agents. A customer whose 

30 CTA 2 has just received a trcket 8 may only use that 
ticket upon successful completkxi of the transaction. 
[0038] As described in WO-A-95/30211, trusted 
agents support a variety of ticket types used for varbus 
purposes. However, of primary importance for the 

35 present invention are credential tickets and electronic 
rrxxiey purchase receipt tickets. A credential ticket iden- 
tifies the "owner" and pennits specific privileges. Exam- 
ples of credentials include credit and debit cards. A cred- 
it or debit card ticket can be presented for authorization- 

^ based payment. A customer's receipt ticket identifies 
the particulars of a distribution transaction (buying or 
selling of electronic money), and may be used by the 
customer in a dispute scenario. 
p)039] Figure 2 shows a preferred embodiment of a 

^ ticket 8 in which the ticket is comprised of six major sec- 
tions: Identifier 10, Components 12, Issuer Signature 
14, Issuer Certificate 1 6, Transfer History 1 8 and Sender 
Signatures 20. The sections, in turn, are comprised of 
varbus informatbn ccxitaining fields. 

50 [0040] The Identifier section 10 has a field 22 which 
holds information that identifies the merchant or author- 
ity creating the ticket. Such informatbn, for example the 
merchant's or authority's name, is copied from a mer- 
chant or authority credential held by the ticket issuer. 

55 The fiekJ 22 also contains the expiration date of the mer- 
chant or authority credential. A field 24 contains the re- 
ceiving trusted agent's kJentificatbn number The field 
24 also contains the expiratk>n date of the tbket receiv- 
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er*s trusted agent credential. A field 26 designates the 
ticket type (e.g.. credit or debit card ticket, receipt ticket, 
etc.). 

[0041] The Components section 1 2 contains the basic 
ticket content which varies depending upon the ticket 
type and its specific purpose. Figure 2 shows examples 
of components found in different ticket types. 
[0042] A credential ticket such as a credit or debit card 
way have: a Bank ID field 36 specifying the credential 
owner's bank; an Account Number fiekl 38; a N^lid From 
Date field 40; an Expiration Date field 42; and a Cus- 
tomer Name field 44. 

[0043] An electronic money purchase receipt ticket 
nnay have: a Bank ID field 46 specifying the bank iden- 
tified in the customer's credential; an Account Number 
field 38 specifying the account number identified in the 
customer's credential; a Type of Transactkx) fiek) 50 
specifying whether the transactk)n is an electronic mon- 
ey purchase or sale; an Authorization Amount fieki 52; 
an Amount Sent or Received field 54; a IMerchant Pee 
fieki 56; and a Date of Transactk>n field 58. The author- 
izatk>n amount equals the amount received plus the 
merchant's fee for the purchase transactbn or the 
amount sent minus the merchant's fee for a sale. 
[0044] The Issuer Signature section 14 of a ticket 8 
holds a digital signature, formed by the ticket creator, 
over the Identifier and Components sectkxis 10, 12, 
Such signature is made using a private key belonging 
to the issuer's trusted agent. The Issuer Certifk:ate sec- 
tk>n 16 contains a certrficatkx) by a trusted third party 
(hereinafter referred to as the "Trusted Agency') used 
in conjunctbn with the issuer signature to verify the au- 
thenticity of the issued ticket 8. Such certification is in 
the form of a certificate bek>nging to the issuer's trusted 
agent. The general use of certificates and digital signa- 
tures is known arKj described, for example, in D.W. Dav- 
ies and W.L Price, Security For Computer Networks 
(John Wiley & Sons. 1984). 

[0045] The Transfer History section 1 8 contains infor- 
matkxi generated when tk:kets are transferred between 
trusted agents after the initial issuing of the ticket 8 by 
a merchant or authority. A Receiver ID'S field 28 contains 
the receiving trusted agenfs kientifkatkxi number. A 
Sender I D's field 30 contains the sending trusted agenfs 
kientificatkxi number. A Sender Certs field 32 contains 
the sending trusted agenfs certificate. A Date/Times 
field 34 contains the date ar^j fime of transfer of the tk:k- 
et 8. As subsequent transfers are made, additk)nal re- 
ceiver and sender ID'S, sender certificates, and dates 
and times are appended to each fieki, thus creating a 
list of transfer history informatkxi. It may be noted that 
the trusted agent ID found in the Receiver fieki of the 
Identifier sectkvi, shoukJ be the same as the first ID in 
the Sender ID'S field. 

[0046] In additksn, whenever a ticket 8 is transferred 
between trusted agents, the sender digitally signs the 
ticket over the five preceding ticket sectkxis using a pri- 
vate key belonging to the serKier's trusted agent. The 



Sender Signatures section 20 is then updated by ap- 
pending the newly created digital signature, thus form- 
ing a list of sender signatures. 

5 Transaction Devices 

[0047] Referring to Figure 3, a trusted agent 120 is 
embedded in a transaction device 122. The transaction 
device 122 is composed of three major components for 

10 both the merchant and the customer. There is a host 
processor 124, a trusted agent 120, and a money mod- 
ule 6. These components are connected, for example, 
by a bus 126. When trusted agent 120 is a MTA 2, the 
device 122 is referred to as a merchant transaction de- 

^5 vice (I^D). When trusted agent 1 20 is a CTA 4, the de- 
yncB 122 is referred to as a customer transaction device 
(CTD). 

[0048] Figure 3 shows the functional components of 
the host processor 1 24. The host processor provides the 

20 following functkxis: Communications 128. Transaction 
Applk3t»ns 130, Human/Machine Interface 132, Date/ 
Time 1 36, and a Message Manager 1 34. 
[0049] The Communications function 128 supports 
communications between the transactk>n device 122 

25 and the outskJe world. Such communications may be 
wired or wireless, broad or narrow t>and. so long as com- 
munications are compatible between the devices. The 
Communications function 128 sets up the connection 
between two transaction devices 122, or connects a 

30 transactk>n device to a network for indirect connectbn 
to another transaction device or a trusted server 
[0050] Transaction Applicatkxis 130 may perform a 
variety of tasks. For example, a transaction applicatkxi 
may shop the merchant networks for the towest mer- 

35 chant transaction fee and/or the best exchange rate in 
an electronic money purchase or sale transaction. In 
general, a transactkxi device 122 contains all the proc- 
esses to choose, buy and possibly use electrons ob- 
jects, electronic money, credentials, and other tickets 8, 

"fo or the processes to sell the same. 

[0051] The Human/Machine Interface function 132 
provkies the look and feel of the transaction devbe 1 22. 
It could include a keyt)oard, mouse, pen, voice, touch 
screen, icons, menus, etc. The Human/Machine Inter- 

^ face 1 32 communicates with other functions in the trust- 
ed agent 1 20 and the money nrxxJule 6 through the mes- 
sage manager 1 34. In some applications a Human/Ma- 
chine Interface 1 32 may not be necessary, for example, 
in a fully automated merchant transaction device. 

50 [0052] The Date/Time f unctton 1 36 is set by the owner 
of the transaction device 122 and includes date, time 
and time zone. The Date/Time information is fed to the 
embedded trusted agent 120 whenever the trusted 
agent is opened for use. 

[0053] The Message Manager 134 routes inter-host 
messages (i.e., messages between transaction devk:- 
es) and messages anDong the host processor 124, the 
trusted agent 120 and the money module 6. 
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Trusted Agents 

[0054] Figure 4A shows the functional components of 
a trusted agent 1 20. The contemplated system for open 
electronic commerce uses three types of trusted agent 
120 which differ in certain unique Transactor functions 
146 that they provide. Figure 4B shows the transactor 
functions found in a CTA 2. Figure AC shows the trans- 
actor furKtions found in a MTA 4. Figure 4D shows the 
transactor functions found in an Authority Trusted Agent 
(ATA) which, in tum, is embedded in an Authority Trans- 
action Device (ATD). ATDs are associated with creden- 
tial issuing authorities such as a bank. 
[0055] An External Interface function 138 provides 
physical communication with the host processor 124 
and the money nrxxlule 6 of the transaction device 122 
in which the trusted agent 1 20 is embedded. A Message 
Interface function 140 processes and routes inter-agent 
and intra-agent messages. A Session Manager function 
142 sets up and breaks down inter^gent sessions and 
agent to trusted server sessions. A Security Manager 
f unctkxi 1 44 maintains security information (e.g. , a trust- 
ed agent certificate and an untrusted agent list) and es- 
tablishes secure communication with a counterparty 
trusted agent (via the host processor 124) and with the 
kx^al money module 6 within the same transaction de- 
vice 122. The Transactor functon 146 provides the pro- 
tocols to perform a transaction. Customer, merchant 
and authority transactors are used for CTAs, MTAs and 
ATAs. respectively- 

[0056] Figu re 4B shows the customer transactor func- 
tkwis. A Purchase function 158 exchanges payment for 
tickets 8 and electronic objects. A To Host function 160 
provides an interface to the transactkxi device's host 
processor 124. A Present Tcket function 164 presents 
tickets 8 to obtain information or sen^ices. An Acquire 
Credential functkxi 166 interacts to receive a credential 
ticket. A Tran Log function 1 62 maintains a log of trusted 
agent transactior^. Both CTAs 2 and MTAs 4 maintain 
a transaction log which stores the following information: 
transaction type (e.g.. ticket type); a pre-transaction 
ticket image; a post-transaction ticket image; dispute in- 
formation including the date of dispute (as maintained 
by each trusted agent in the dispute dialog), status, and 
merchant resolution (e.g.. replace, refund, dented); and 
recertifying information (e.g., date of recertificatkxi). An 
Initiate Dispute function 168 presents electronic mer- 
chandise if a customer is dissatisfied. 
[0057] Figure 4C shows the merchant transactor 
functk^ns. A Purchase function 170 exchanges tickets 8 
and electronic objects for payment. A To Host function 
172 provkies an interface to the transactkxi device's 
host processor 1 24. A Receive Ticket function 1 76 proc- 
esses a received tbket 8 to provkie sennce or informa- 
tkxi. An Acquire Credential function 177 obtains a mer- 
chant credential. A Tran Log function 174 maintains a 
bg of trusted agent transactkxis. A Resolve Dispute 
furtctkxi 178 receives tbkets 8 and electronic objects to 



resolve a customer complaint. 
IPOSS] Figure 4D shows the authority transactor func- 
tions. A Create Credential f unctbn 1 80 constructs and 
delivers credential tickets to a requestor A To Host f unc- 

s tion 1 82 provkJes an interface to the transaction device's 
host processor 1 24. A Receive Ticket function 1 84 proc- 
esses a received ticket 8 to provide service or informa- 
tion. A Revalidate Credential function 1 86 accepts a cur- 
rent credential and reissues the credential with a new 

10 expiratran date. A Tran Log f unctton 1 83 maintains a log 
of transactions. An Acquire Credential function 185 ob- 
tains an authority credential. 

Referring again to Figure 4A. a To Money Mod- 
ule function 150 communk^ates with the rtKjney module 

15 6 in the same transaction devk:e 122 to provide pay- 
ment. A Cryptography function 152 provides publk: key 
and symmetry key cryptographic functkxis. Any well 
known public artd symmetric key cryptography tech- 
nk^ues may be used, for example, RSA and DES. A Tick- 

20 et Holder function 148 creates tbkets 8 in a MTA 4 or 
stores and retrieves tickets 8 in a CTA 2. A Random 
Number Generator functbn 156 generates random 
numbers to produce cryptographk: keys. A Date/Time 
function 1 54 manages the date and time delivered from 

25 thehostprocessor124todatetickets8andvalklatecer- 
tifk:ates and presented tickets. Current clock informa- 
tion is fed to the trusted agent 1 20 every time the trusted 
agent is opened (i.e. , signed on for use) and maintained 
until the trusted agent is cbsed. 

30 [006G] The trusted agent/money module hardware 
mayconsistof the foltowing: a microcontroller (e.g., Intel 
196 family) for executing the transaction protocols; a 
highspeed volatile menrwry (e.g., SRAM) for storing the 
operating system, parts of the applications, cryptogra- 

35 phy. etc. during executbn; a non-volatile memory (e.g., 
flash memory) for storing the operating system, appli- 
cations, tickets, electronic money, bgs, etc.; an integrat- 
ed circuit clock for provkiing a time reference; a battery 
for the ckx:k; and a noisy diode or other random source 

40 for a random number generator. 

System Overview 

[0061] Figure 5 shows the general network architec- 
ts ture of the contemplated system for open distribution of 
electronk: money. Customer transaction devrce 188 can 
communbate with a merchant through any gateway net- 
work 190. The customer can search out merchants' 
electrons space for the purchase or sale of electronk: 
50 money, arrd select the merchant offering the lowest 
transactk)n fee and/or exchange rate. The system then 
provides for secure authorization-based purchase/sale 
of electronic money via credit or debit card. This is ac- 
complished by the customer presenting credit or debit 
55 card information stored within the trusted agent 1 20 as 
a credential. 

[0062] In the preferred embodiment, the gateways 
190 provide CTDs 188 with access to kx:al merchant 
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networks 1 34 that are connected to MTDs 1 98. The mer- 
chant network 1 34 is connected to the merchant's bank 
network 200 that, as described in WO-A-93/10503, has 
access to electronic money via money generator nrKxJ- 
ule 202, teller money nrKxJule 204, and banking system 
206 which provides the bank's on^ine accounting sys- 
tem. 

[0063] The credit or debit card credentials are proc- 
essed to obtain authorizations for the crediting or deb- 
iting of the customer's bank account via authorization 
network 208. Card authorizatkxi is well known in the art 
and typically involves the card issuer or its agent author- 
izing a particular payment when sufficient functe are 
present or the amount is within the card holder's credit 
limit. Authorization networks also credit a customer's ac- 
count, for example, when making a refund. Authoriza- 
tk>n network 208 is connected to the customer's bank 
network 200 whk:h, in turn, is connected to banking sys- 
tem 206, whk:h contains the customer's bank account. 
[0064] This architecture alk>ws subscribers who are 
not customers of electronic nrK>netary system member 
banks to nevertheless gain access to electronic money 
via merchants who do have access to member banks. 
This system structure allows the subscriber to buy or 
sell electronic money from many distribution points, 
whk^h from the subscriber's point-of-view is effectively 
the same as withdrawing or depositing electronic money 
from/to their bank account. 

[0065] It should also be noted that an electronic mon- 
etary system bank could also provide the above-de- 
scribed distribution service via an MTD 1 98. In this case, 
of course, there wouki be no need for a mercfiant net- 
woric 134. The bank network 200 woukl simply connect 
to a money generator module 202, teller money nrxxiule 
204, tianking system 206, MTD 1 98, authorizatkxi net- 
work 208, and gateway network 190. Otherwise, the 
transaction would be the same. 

Flow Charts 

[0066] The flow charts sfiown in the following figures 
use the designations "A" and "B" to indk^te two inter- 
acting trusted agents 1 20. The same designations A and 
B, may also be applied to the host processor 124 or 
money module 6 associated with a particular trusted 
agent 120 (i.e., within the same transactk)n devk^e 122). 
The flow charts indicate the furtctkxial component pri- 
marily responsible for carrying out a given task. For ex- 
ample, SECURITY MANAGER A means that the recited 
task is carried out by the Security Manager f unctkxi 1 44 
(see figure 4A) in trusted agent A. 
[0067] The flow charts also call subroutines some of 
whk^h use parameter designatkxis X and Y For exam- 
ple, ESTABUSH SESSION A -> B is a call to the sub- 
routine Establish Sesskxi. The Establish Sesskxi flow 
chart shoukt then be followed with the urKierstanding 
that X - A and Y = B throughout the fk>w. 



Abort And Comrnit 

[0068] In transaction processing of the type contem- 
plated it is desirable to pass electrons items such as 
s tickets 8 and electronk: notes between two parties, while 
maintaining a zero-sum game. In other words, it is un- 
desirable to duplicate electronic items so that at the 
completion of an electronic transaction there are twice 
as many items as before the transaction. Similarly, it is 
undesirable to tose electrons items so that there are 
fewer items after the transaction than before. For exam- 
ple, if at the start of a transaction A has an electronic 
ticket 8 and wishes to pass it to B, then it is desirable to 
ensure that at the end of the transactbn, B has the elec- 
tronic tk:ket 8 and A does not have the electronk: ticket 
8. In the real world, however, it is possible to have two 
other outcomes, namely, both A and B have the same 
electronk; ticket 8 (duplication) or neither A nor B have 
the electronic ticket 8 (loss). 

[D069] In order to render the likelihood duplicatbn 
or k>ss negligible, the transactk)n protocol must take into 
account the possibility that natural or intentbnal events 
may interrupt a typical transaction flow. A natural inter- 
ruption is exemplified by a breakdown of the communi- 
cations link between A and B during the transaction. To 
minimize the possibility of duplk:ation or loss from such 
a random event the window of opportunity for creating 
a duplk^ation or bss must be minimized. In order to min- 
imize intentional interruptbns (i.e., overt attacks), it is 
desirable to eliminate the economic incentive for such 
an attack. For example, if an attacker could only lose 
the tk:kets and or the money by trying to interrupt a trans- 
action, the attacker would have no Incentive to initiate 
the attack in the first place. 

[0070] These concepts are embodied in the efficient 
transactkjn protocols of the described system. In partic- 
ular, it is desirable to ensure consistent abort and com- 
mit states between the two transacting trusted agents 
120 (or money nrKxlules 6). For example, if A commits 
to a transaction, then B shouW also commit to the trans- 
action; or, if A aborts the transaction, then B should also 
atx>rt the transactbn. To achieve consistency and min- 
imize the possibility of duplication or bss (in the event 
there is an inconsistency) the transaction protocols take 
into account the order and timing of A's and B's commit- 
ting to a given transaction. 

p)071] Figure 6 shows two subroutines, Abort and 
Commit. The abort subroutine is internally executed 
within a given trusted agent 1 20 when the transaction it 
is involved in fails. The abort subroutine rolls back or 
returns the trusted agent 1 20 to the exact state it was in 
prbr to being involved with the failed transaction. In ad- 
ditkxi, if the merchant trusted agent aborts after an au- 
thorizatbn, then the authorization will be reversed. Con- 
versely, the commit transactbn is intemally executed 
within a given trusted agent 120 when the transaction it 
is involved in has been successfully completed. The 
trusted agent 120 therefore records the completed 



IS 



20 



25 



30 



35 



40 



45 



50 



6 



11 



EP0830 656B1 



12 



transaction in its transaction log and is now ready for a 
new transaction. For example, during a ticket transfer 
transaction an electronic ticket 8 is passed fronrt trusted 
agent A to trusted agent B. Since at this point in time 
neither A nor B have committed or aborted the transac- 
tion. A provisionally retains the ticket 8 while B provi- 
sionally also has the ticket 8. If both A and B commit 
then A will delete its ticket 8, and B's retentbn of the 
tk:ket 8 will no tonger be provlskxial. If. however, both A 
and B abort then A will retain its ticket 8 and the tk:ket 
8 that B was retaining provisbnally wilt be deleted by 
rolling back the transaction. Note that the deletion oper- 
ation may be implemented in various ways well known 
in the art. As mentioned before, it is desirable to mini- 
mize the possibility of one trusted agent 1 20 committing 
while artother trusted agent 120 aborts because this 
may in some limited circumstances result in duplicating 
or k>sing electronic items. 

[0072] A similar srtuatkxi exists with respect to money 
rrK)dules 6 exchanging electronic notes. During a pur- 
chase transaction, electronic notes are passed from 
money module A to money nrKxiule B, so that A provi- 
sionally decrements Its electronk: notes (by the amounts 
transferred) while B provisionally has electronk: notes 
(in the transferred amount). If both A and B commit then 
A will retain the notes in the decremented amounts and 
B's retenton of the electronic notes will no kxtger be pro- 
vtsk>nal. 

[0073] Figure 6A shows the commit subroutine. Tran 
Log X updates the transaction bg. To Host X notifies the 
host that the transactkxi is complete. Session Manager 
X notes the end of the session. (Steps 230 - 234). 
[0074] Figure 6B shows the abort subroutine. Sessbn 
Manager X rolls back changes and notes agent aborted. 
The Sesskxi Manager keeps track of v&taX has been 
done since the start of a sesskxi and when rolling back 
undoes these steps. To Host X sends a message to the 
host that the transaction is aborted. (Steps 236 - 238). 
[0075] The abort subroutine may be called directly 
from a flow diagram, for example, when a trusted agent 
120 determines that a certificate is not valid. The abort 
subroutine may also be called when an expected action 
does not occur. In partbular, when two trusted agents 
120 are communk^ting, they will be monitoTDng a time- 
out protocol. For example, after a first trusted agent 1 20 
has sent a message to a second trusted agent 120, the 
Sessk>n Manager of the first trusted agent (A) will set a 
timer for a reply if a reply is required. The Session Man- 
ager may also number the message sent. This number 
woukj appear in the reply message from the Session 
Manager of the second trusted agent (B). 
[0076] If the timer expires before the message has 
been received, then Session Manager A will query Ses- 
sion Manager B to determine if the transactkxi is still 
running in B. If B does not reply then Session Mariager 
A will abort the transactbn. If a reply is received that the 
transaction is proceeding, then the timer will be reset to 
a new time. If A queries B a predetermtrYed number of 



times without receiving a reply to the original message, 
then A wjll abort the transaction. A similar time-out func- 
tion exists in the money modules 6. 

5 Purchase/Sale of Electronic Money 

[0077] Figure 7 shows the flow chart for an authoriza- 
tion-based purchase/sale of electronic money. When 
the owner of a trusted agent A wants to buy or sell elec- 
tronic money by debiting or crediting his bank account, 
he uses a transaction application in his CTD 1 88 to shop 
the merchant networks 134 for the lowest merchant 
transaction fee and/or exchange rate and selects, in this 
example, the merchant owner of trusted agent B (steps 
700 - 702). It may be noted that, altematively, the au- 
thorization network could set the exchange rate. 
[0078] Host transactkjn application A (HTA) then con- 
nects to host transactbn application B (HTB), whereup- 
on the customer chooses the type of transaction, name- 
ly a purchase or sale of electron k: rrK>ney (step 704). 
hfTA sends a message to its trusted agent A to buy (sell) 
electronk; money, and HTB sends a message to its trust- 
ed agent B to. send (receive) electronk: money (steps 
706 - 708). 

[0079] The customer's and merchant's trusted agents 
(A and B) then establish a sessbn as described in WQ- 
A-95/30211. In partfcular, an Establish Session subrou- 
tine is called (step 710) for setting up a cryptograph really 
secure communicatbn channel between trusted agent 
A and trusted agent B. Referring to Figure 8, the Session 
hAanager of trusted agent A requests and then receives 
A's certificate (i.e., cert(TA)) from the Security Manager 
(steps 296 -298). Session Manager A then sends cert 
(TA) to trusted agent B's Session Manager which, in 
turn, passes it along to its Security Manager (steps 300 
-304). 

[0080] Trusted agent B's Pubib Key functbn verifies 
the cert(TA) by using the validatbn protocols such as 
those discussed in WO-A-95/30211 and WO-A- 
96/33476 (steps 306 - 308). 

[0081] If cert(TA) is not valkJ, then Session Manager 
B notes that the session is terminated and informs Ses- 
sbn Manager A that the transactbn is denied. Sessbn 
Manager A also notes that the sessbn is terminated. 
(Steps 31 0 - 31 2). If certfTA) is valb, then Security Man- 
ager B checks if trusted agent A is on the untrusted list 
(steps 314 - 316). If trusted agent A is untrusted, then 
the session is terminated (steps 310 - 312). 
[0082] If A is not on the untrusted list, then Random 
Number Generator B creates a random number R(B) 
and also a B verification message (step 318). The ran- 
dom number R(B) will eventually be used to form a ses- 
sion key. The B verification message is a random 
number used by B to protect against message replay 
Next. Security Manager B assembles R(B). the B veri- 
fbation message, and cert(TA) into a message for trust- 
ed agent A (step 320). Public Key B encrypts the mes- 
sage using trusted agent A's public key (TA(PK)) whbh 
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trusted agent B received with A's cert(TA) (step 322). 
Session Manager B sertds the encrypted message to 
A*s Session Manager (steps 324 - 326). 
[0083] Public Key A decrypts the message using its 
private key (corresponding to its public key) and verifies 
the validity of cert(TA) (steps 328 - 330). If cert(TA) is 
invalid, then Session Manager A notes the session as 
terminated and sends a transaction denial message to 
B whose Sessk>n Manager also rrotes the session as 
terminated (steps 332 - 334). If cert(TA) is valid, then 
Security Manager A checks if trusted agent B is on the 
untrusted list (steps 336 - 338). If trusted agent B is on 
the list, the sesson is terminated (steps 332 - 334). 
[0084] If B is not on the untrusted list, then Random 
Number Generator A creates a random number R(A) 
and an A verification message (e.g., another raruJom 
number) (step 340). The Date/Time f unctk>n passes the 
current date arKl time to the Security Manager (step 
342). Dates and times are exchanged by A arKJ B for 
eventual recording in their trans logs during commits. 
Security Manager A then forms and stores session key 
(TA/TA) by exclusive ORing random numbers R(A) and 
R(B) (step 344). Session key (TA/TA) is used to encrypt 
communk:atk)ns between two trusted agents 120. Ses- 
sion Manager A assembles a message containing the 
A and B verification messages, the date/time tnforma- 
tkxi, and R(A) (step 344). Public Key A encrypts the 
message with trusted server Bs public key (received by 
A in certfTA)) and sends the encrypted message to trust- 
ed server B's Sessnn Manager (steps 346 - 350). 
[0085] Public Key B decrypts the received message 
using its secret key (corresponding to its public key) 
(step 352). Security Manager B checks if the B verifica- 
tion message received from A is the same B verificatkxi 
message it previously sent to A (steps 354 - 356). If it is 
not the same, then the session is terminated (steps 310 
- 31 2). If it is the same, then Sesskm Manager B notes 
the start the session (step 358). 
[0086] Security Manager B forms sesskxi key (TA/T A) 
by R(A) XOR R(B) and then stores the sessk)n key (step 
360). At this point, both A and B have created and stored 
the same session key (i.e., sesskxi key (TA/TA)) to be 
used for their current interactkxi. Next. Date/Time B 
serKJs its current date and time informatbn to Security 
Manager B (step 362). Security Manager B assembles 
a message having an acknowledgement to A, the A ver- 
ification message, and B*s date/time informatkxi (step 
364). The Send Message subroutine is then called (step 
366) for sending the message from B to A. 
[0087] Referring to Figure 9. trusted agent &s Sym- 
metric Key function encrypts the message using session 
key (TA/TA) (step 376). Message Interface B then for- 
mats the message and sends it to the host processor's 
Message Manager (step 378). Host Message Manager 
B then routes the message via Communications to Host 
Message Manager A in trusted agent A*s host processor 
(step 380). Host Message Manager A then sends the 
message to trusted agent A's Message Interface which 



strips out the message (steps 382 - 384). Symmetric 
Key A decrypts the message with sessbn key (T/VTA) 
thus completing the secure communicatbn of a mes- 
sage between trusted agent and trusted agent using 
s sessbn key (TA/TA) (step 386). 

[0088] Referring again to Figure 8, Security Manager 
A receives the acknowledgement, A verification mes- 
sage and B's date/time Information (step 368) . Security 
Manager A checks if the A verification message is the 
same A verification message which A prevbusly sent to 
B (steps 370 - 372). If it is not the same, then Session 
Manager A terminates the session (steps 332 - 334). If 
it is the same, then Session Manager A notes the start 
of the session (step 374). 

[0089] Referring again to Figure 7, after establishing 
a session, trusted agent A requests and checks the mer- 
chant credential of trusted agent B, also as described in 
WO-A-95/30211 . In particular, referring to Figure 10. the 
Check Credential subroutine is called (step 712). All 
MTDs 1 98 contain a credential kientifying the owner/ 
merchant (e.g., NYNEX, Tlcketron, etc.). Such mer- 
chant credentials may, for example, be issued by a mer- 
chant identificatbn authority controlled by the Trusted 
Agency. On the other hand, customer credentials held 
by CTDs 188 may include driver's licenses or credit 
cards issued by various identification authorities. Refer- 
ring to Figure 10, Purchase A sends a message to Pur- 
chase B of trusted agent B requesting its merchant cre- 
dential (steps 444 - 448). Ticket HokJer B retrieves its 
merchant credential and sends the credential to A for 
validatbn (steps 450 - 456). 

[0090] Credentials or any other type of ticket 8 are val- 
idated as follows: 

1 ) Validate issuer certificate and check issuer sig- 
nature. 

2) Verify each transfer - match receiver and sender 
bentifiers (i.e., = Issuer, = 1st receiver, then 
Ri = S^i,i^). 

3) Valbate each sender certificate and check each 
sender signature. 

4) Verify that the last receiver bentifier matches the 
bentifier (TA(id)) of the certificate (cert(TA)) of the 
trusted agent in the current sessbn. 

[0091] If the merchant's credential is not valid, then 
the transactbn is aborted by calling the Abort Transac- 
tion subroutine (step 458). Referring to Figure 11 , trust- 
ed agent A aborts (step 388) and its Sessbn Manager 
sends a message to trusted agent B's Session Manager 
informing B that A has aborted (steps 390 - 394). Tmsted 
agent B then aborts (step 396). Referring back to Figure 
10. if the merchant's credential is valid, then To Host A 
sends the credential information to a host transfer ap- 
plicatbn for confirmation (e.g.. visual confirmatbn of 
nrmrchant name by CTD hober) (steps 460 - 462). 
[0092] Referring again to Figure 7, the flow for the pur- 
chase/sale of electronic money continues. To Host A re- 
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quests the amount of electronic money and in which 
monetary unit (e.g.. dollars, yen, pounds, etc.) it wishes 
to buy or sell (step 714). The customer or a surrogate 
process enters this information which is received by Pur- 
chase A and sent to trusted agent B (steps 716-718). 
[0093] Purchase B receives the message and checks 
if it is to receive electronic money (steps 720 - 722). If 
so, then it sends a message to trusted agent A request- 
ing a bank credit or debit credential (steps 750 - 752). 
Ticket Hokier A receives the message and sends a list 
of possible credentials to HTA (step 754). A credential 
is picked ami the choice is sent to the trusted agent A 
(step 756). Ticket Hokier A then retrieves the selected 
credit or debit card credential and Purchase A sends it 
to Trusted Agent B (steps 758 - 762). 
[0094] Purchase B then validates the credential as 
described prevk>usly (steps 764 - 766). If the credential 
is rK>t valid, then the transactnn is aborted. If it is valid, 
then Ticket htolder B creates an electronic money pur- 
chase receipt, and Purchase B sends the receipt to 
trusted agent A (steps 768 - 772). 
[0095] Purchase A receives the receipt and checks rf 
it is vaiki (steps 774 - 776). If not vaiki, then the trans- 
action is aborted (step 778). If it is valid, then Purchase 
A sends receipt information to the HTA for purchaser 
confirmatkxi (steps 780 - 782). If not confirmed, then the 
trcinsactkxi is aborted, otherwise. Purchase A sends the 
receipt to Ticket Hokier A (steps 784 - 786). 
[0096] Purchase A then sends a message ackrtowl- 
edging receipt to tmsted agent B (steps 788 - 790). Pur- 
chase B then checks if electronic money is to be re- 
ceived (steps 792 - 794). If so, then To Host B sends a 
message with amount and credential to the card author- 
izatkxi network 208 to credit the bank account kientified 
by the credential (step 796). Foltowing the card author- 
izatkxi process (step 798). Purchase B checks if the 
credit was authorized (steps 800 - 802). If nc^. the trans- 
action is aborted, otherwise Purchase B sencte a mes- 
sage to trusted agent A that the credit was authorized 
(steps 804 -806). 

[0097] Trusted agent A then performs a money mod- 
ule payment to trusted agent B as described in WO-A- 
95/30211 . In partkiular, a Money Module Payment sub- 
routine is called (step 808). Referring to Figure 12. Ran- 
dom Number Generator A creates random number R(1 ) 
(step 520). Pu rchase A then sends a message to trusted 
agent B irKitcating that a "money module payment" will 
be made and also containing R(1 ) (step 522 - 524). Pur- 
chase B receives the message and sends R(1 ) to Se- 
curity Manager B (steps 526 - 528). Random Number 
Generator B creates random number R(2) and sends it 
to trusted agent A (steps 530 - 532). Security Managers 
A and B both form sesskxi key (TA/MM) by exclusive 
ORing R(1) and R(2) (Steps 534 - 536). 
[0098] Referring to Figure 1 3, there is shown four en- 
cryptkMD channels established during a transactbn. En- 
cryptkxT) channel 436 between the two trusted agents 
120 carries messages encrypted by sesskm key (TA/ 



TA). Channels 438 and 440 between a trusted agent 1 20 
and its money module 6 share sessbn key (TA/MM). 
Channel 442 between money nrrodules 6 in different 
transactkxi devices 122 use sessbn key (MM/MM). 

s [0099] Session key (TA/MM) is used for encrypting 
messages sent between a trusted agent 120 and its as- 
sociated money module 6 via encryption channels 438 
and 440. At the present point in the flow diagram, only 
the two trusted agents 120 have session keys (TA/MM). 

10 Both money modules 6 will later in the flow diagram form 
copies of sessbn key (TA/MM) so as to enable encrypt- 
ed communicatbn between the trusted agents 120 and 
their money modules 6. 

[0100] It may be noted that instead of the trusted 
IS agent 1 20 and money module 6 being embodied as dis- 
crete tamper-proof components, they may be fabricated 
as one tamper-proof module. In this case, it wouki not 
be necessary to establish a secure sessbn for commu- 
nication between trusted agent 120 and money module 
20 6 in the same transaction devbe 1 22. hlowever, discrete 
money modules 6 and trusted agents 1 20 are preferable 
In that such a configuration allows for greater application 
flexibility. 

. [0101] Referring back to Figure 1 2, To Money Module 

25 A sends a 'Make Payment' message and R(1 ) to its as- 
sociated money module A. Also. To Money Module B 
sends a 'Receive Payment' message and R(2) to its as- 
sociated money module B (steps 538 - 544). 
[01 02] At this stage, money module A (within the CTA 

30 2) and money module B (within the MTA 4) establish a 
sessk)n between them so that each money module 6 
winds up holding new session key (MM/MM) (step 546). 
In establishing this rrxxiey module to money module 
sessbn, the money modules exchange messages via 

35 the pre-existing trusted agenfs sessbn. Referring to 
Figure 13. the session key for encryption channel 442 
is formed by exchanging messages encrypted by chan- 
nel 436. After the money module session is established, 
messages sent between money nrxxiutes will be en- 

40 crypted twice, by both session key (MM/MM) and ses- 
sbn key (TA/TA), abng the portion of the communba- 
tion path between trusted agents 120. 
[01 03] In the preferred embodiment, the money mod- 
ule session is established in a manner similar to the es- 

45 tablishment of a trusted agent session. The money mod- 
ules 6 wouW therefore hoW their own certificates con- 
taining their public keys. The swapping of certifbates 
and random numbers (for XORing) enables the secure 
creation of session keys (MM/MM). The Establish Ses- 

50 sbn protocol used by money modules is described in 
WO-A-96/33476 and is shown in Figure 14. Maintain 
Security A sends the module certifbate to the sessbn 
martager. arxi Sessbn Manager A receives the certifi- 
cate and checks if money nrxxiule A is connected to the 

55 netwoilc (steps 1464 - 1466). If money module A is not 
connected to the network, then Sessbn Manager A 
sends the certificate received from Maintain Security A 
to destination B (step 1476). 
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[0104] AttemativeJy, if money module A is connected 
to the network, then Symmetric Key A encrypts the cer- 
tificate with K and Session Manager A sends the en- 
crypted certificate to the network sender (step 1468 - 
1472). The Network Server decrypts the certificate with 
K and sends the certificate to destination B. 
[0105] Regardless of whether the certificate was sent 
by the Network Sender or by Session Manager A. Ses- 
sion Manager B receives the certificate and Maintain 
Security B (if B is a security server, then this function is 
perfonrrted by the Sesswn I^Aanager) validates the cer- 
tificate (steps 1480 - 1482). If the certificate is not valid, 
then Sesskyi Manager B notes the session is terminated 
and informs either the subscriber or the bank (steps 
1486 - 1492) (rf B '^ a security sender, then B merely 
notes the transactk)n is tenminated). 
[0106] If the certificate is vaiki, then Maintain Security 
B checks if A is on the bad id list (steps 1494 - 14%). If 
A is on the list then the session is tenminated. If A is not 
on the list, then Random Number Generator B creates 
random number R(B) and a B verification message (step 
1498). Ckx:k/Hmer B retrieves the time and date (step 
1500). Maintain Security B assembles R(B), B verifica- 
tk>n message and time and date in a nriessage (step 
1502). Publk; Key B encrypts the message with A's pub- 
Ib key and Session Manager B appends B's certificate 
to the encrypted message and sends the message to A 
(steps 1504-1506). 

[0107] Session Manager A receives the message, 
Public Key A decrypts the encrypted part of the mes- 
sage, artd Maintain Security A validates B's certificate 
(steps 1508 - 1514). If the certificate is not valkJ, then 
Sesskxi Manager A notes the termination of the session 
ax\6 informs either the subscriber or the bank (steps 
151 6 - 1522). If the certificate is valkJ, then Maintain Se- 
curity A checks if B is on the bad id list (steps 1 524 - 
1526). If B is on the list, then the session is tenminated. 
If B is not on the list, then Maintain Security A retrieves 
the date and time and compares it to B's date and time 
(steps 15^ -1530). If the date and time are out of range, 
then the sessksn is temrtinated. 
[01 08] If the date and time are in range, then Random 
Numt>er Generator A creates random number R(A) and 
an A verification nnessage (step 1532). Maintain Secu- 
rity A then forms a session key by the operatkxi R(A) 
XOR R(B) (step 1534). The A verification message, the 
B verification message, the time, date and R(A) are as- 
sembled into a message and ericrypted with B's public 
key (step 1536). The message is sent to B by Sesskxi 
Manager A (step 1538). Sesskxi Manager B receives 
the message. Public Key B decrypts the message and 
Maintain Security B checks the B verificatKm message 
(steps 1540 - .1546). If the B verification message is in- 
correct, the session is terminated. If the B verificatkxi 
message is correct, then l^ntain Security B forms the 
session key by R(A) XOR R(B) (step 1548). The time 
and date are retrieved and compared to A's time and 
date to check if they are within a predefined range of 



each other (step 1550). If the time and date are out of 
range, then the session is terminated. If the time and 
date are in range, then Session manager B notes the 
start of the session (step 1552). 
5 [0109] Sessbn Manager B then sends an acknowl- 
edgement and the A verification message to A (steps 
1 554 - 1 556). Session Manager A receives the message 
and Maintain Security A checks the A verification mes- 
sage (steps 1558 - 1562). If the verification message is 
r)ot correct, the sessbn is terminated. If the verification 
message is correct, then Session Manager A notes the 
start of the session (step 1564). 
[0110] The overall system security pertaining to the 
money modules may be integrated with that for the trust- 
ed agents 1 20; but is preferably separate to provide for 
enhanced system security and system flexibility. 
[0111] Refem'ng back to Figure 12, money module A 
sends R(1) to money module B. This functbn may be 
initiated by a MM Maintain Security A appticatk>n reski- 
ing in money module A (step 548). TTiis applbation artd 
other money module applications are prefaced by the 
designations "MM" and are described in WO-A- 
93/10503 together with any modificatkxis and/or addi- 
tions disclosed in WO-A-95/30211. 
[Oil 2] Random number R(1 ) is sent from money mod- 
ule Ato money module B by the subroutine Send Routed 
Message (step 550). Referring to Figure 1 5. MM Sym- 
metric Key A encrypts the message (Including R(1 )) with 
sessbn key (Mt^4/MM) (step 640). MM Sessbn Manager 
A sends the message to Host Message Manager A 
which, in turn, sends the message to Message Interface 
A of trusted agent A (steps 642 - 646). Trusted agent A 
then sends the message to Message Interface B of trust- 
ed agent B using the Send Message subroutine (step 
648) which encrypts and decrypts the message with 
sessbn key (TA/TA) In between the trusted agents. Mes- 
sage Interface B then sencte the message to MM Ses- 
sbn Manager B in money module B via Host Message 
Manager B (steps 650 - 654). Finally. MM Symmetric 
Key B decrypts the message with sessbn key (MM/MM) 
(step 656). 

[0113] Referring again to Figure 12, MM Maintain Se- 
curity B (in money module B) fonns session key (TA/ 
MM) by exclusive ORing R{1) and R(2). Money module 
B then sends R(2) to rtKxiey module A whbh also forms 
sessbn key (TA/MM) by exclusive ORing R(1) and R(2) 
(Steps 552 - 556). Refemng to Figure 13, at this stage, 
three session keys exist: (MM/MM), (MM/TA), and (TA/ 
TA). Thus, the four encryption channels shown are In 
place. 

[0114] Refemng to Figure 12, MM To Subscriber A 
prompts trusted agent A for the amount of payment by 
type of note (e.g.. dollars, yen, pourxis, etc.) (step 558). 
A money module as described in WO-A-93/1 0503 wou W 
generally use the To Subscriber appllcatbn for commu- 
nbation with the owner/hokJer of the money module. 
However, as used in the present instance, the To Sub- 
scriber application communbates with the trusted agent 
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120 for getting various instructions. Here, the trusted 
agent 1 20 delivers amount of payment and type of note 
Information (trusted agent A has previously communi- 
cated with the owner/holder of the CTD 2 to detemnine 
the amount). 

[0115] The prompt from the money module 6 to the 
trusted agent 120 is sent via the Send MM/TA Message 
subroutine (step 560). Referring to Figure 1 6, MM Sym- 
metric Key A encrypts the message with session key 
(TA/MM) (step 658). MM Session Manager A sends the 
message to tmsted agent A's a Message Interface via 
Host Message Manager A (steps 660 - 664). Symmetric 
Key A decrypts the message with session key (TA/MM) 
(step 666). Refen-lng back to Figure 12, Purchase A of 
trusted agent A sends the arrK>unt (price of selected 
merchandise) by type of note to MM Pay/Exchange A 
of nDoney module A (steps 562 - 566). This message Is 
sent via the Send TA/MM Message subroutine (step 
564). Referring to Figure 17, Symmetric Key A encrypts 
the message with session key (TA/MM) (step 668). Mes- 
sage Interface A sends the message to money nrKxJule 
A's MM Session Manager via Host Message Manager 
A (steps 670 - 674). Finally, MM Symmetric Key A de- 
crypts the message with sesskxi key (TA/MM) (step 
676). 

[0116] Referring to Flgyre 12, MM Note Directory A 
checks if the money rrKxiule 6 has sufficient funds to 
cover the payment (steps 568 - 570). If Insuffrcient, then 
riKxiey rrxxiules A and B abort the transaction (steps 
572 - 582). 

[0117] The MM Abort transactkxi protocol (step 562) 
may be that cl the preferred electronic monetary system 
as described In WO-A-96/33476 and shown in Figure 
18. Session Manager X rolls-back changes and notes 
that the transactkxi is aborted (step 1726). Session 
Manager X then checks if the 'Ready-to-Commit' mes- 
sage has been sent (steps 1728 - 1730). If so, then X 
updates its transaction log (step 1 732) by recording that 
X committed after sending a Ready4o-Commit mes- 
sage and recording the ndte klentifiers and amounts of 
each note received during the Transfer Notes prc^ocol. 
Thus, the abort protocol togs Information when the Abort 
subroutine is called during a failed Commit subroutine. 
[0118] If X 6 a transactkxi money module 1186, and 
the Ready-to-Commit message was sent, then To Sub- 
scriber X Informs Its subscriber that the transactkxi was 
aborted and that there may have been a money transfer 
error (steps 1734 - 1738). 

[0119] If X is a teller money module 1188. then To 
Bank X informs the bank that it shouki reverse its ac- 
counting transacttons (by appropriate debits and cred- 
its) (steps 1 740 - 1 742). If X is a transaction money nrKxi- 
ule 1186 and no Ready-to-Commit message has been 
sent, then To Subscriber X informs the subscriber that 
the transactton was aborted (step 1744). 
[0120] In any event, Sesston Manager X then sends 
Y a message that the transactbn cannot be completed 
(steps 1746 - 1748). Sesston Manager Y rolls-back its 



changes and notes the transaction as aborted (step 
1750). Y then informs its subscriber that the transactbn 
is aborted (steps 1752 - 1754) or informs the bank to 
reverse its accounting transactbn (steps 1756 - 1758). 

5 [0121] As described, if a transactbn is interrupted 
during a commit protocol, it is possible that notes will be 
lost. If this occurs, the transferee will have aborted and 
the transferor will have committed to the transfer of 
notes. In this case, the transferee money module 

10 records infonmation atoouX the notes it should have re- 
ceived and notifies the subscriber that there is a poten- 
tial problem (i.e. it did not receive the notes sent by A). 
It may be noted that in this circumstance, as far as the 
transferor money module is concerned, it properly trans- 

'5 f erred the notes. 

p>122] The transferee money module subscriber can 
then make a claim for the money to the Certificatbn 
Agency. The claim information would Include the tog 
record of the failed transactton. The Certificatbn Agency 

20 couto then check with issuing banks to see if the notes 
have been reconciled. After some period of time, if the 
notes have not been reconciled, the subscriber couto 
reclaim his money 

[0123] Referring again to Figure 12, the messages 

2S between money module A and money module B are 
sent via a Send E-Routed Message subroutine which 
utilizes all three session keys (MM/MM), (TA/MM), and 
(TA/TA). Referring to Figure 19, MM Symmetrb Key A 
encrypts a message with sessbn key (MM/MM) (step 

30 678). The message is then double encrypted by session 
key (MM/TA) before it is sent to trusted agent A. Once 
received by trusted agent A, the message is decrypted 
by sessbn key (MM/TA). (Step 680). Message Interface 
A then sends the message to Message Interface B 

35 (steps 682 - 684). In between tmsted agents 120, the 
message is double encrypted by session key (TA^A). 
tn like manner. Message Interface B sends the message 
to MM Symmetric Key B for final decrypting (steps 686 
- 690). Figure 1 3 illustrates the varbus encryptkxi lay- 

40 ers. 

[0124] Referring again to Figure 12, during the atx>rt 
routines of money modules A and B (step 582), they 
generate messages sent to their trusted agents A and 
B, respectively (steps 584 - 586) infonmmg them that 

45 they have aborted the transaction and hence that pay- 
ment was unsuccessful. Session Managers A and B 
rK>te that the payment was unsuccessful and conse- 
quently trusted agents A and B abort (steps 588 - 598). 
[0125] If, on the other hand, the customer's money 

so rTKxJule 2 has sufficient funds then MM Pay/Exchange 
A sends a message to the merchant's nnoney module 
containing the anrK>unt of money to be transferred in pay- 
ment and the type of notes (step 600). This message is 
sent by the Send E-Routed Message subroutine (step 

ss 602). 

[0126] Money module B receives the message con- 
taining the payment amount according to money module 
A. MM To Subscriber B then sends a prompt to trusted 
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agent B to verify this payment amount (steps 604 - 606). 
Accordingly, Purchase B in trusted agent B verifies if the 
amount is correct (steps 608 - 610). If correct, then trust- 
ed agent B sends a 'Correct Amount' message to mon- 
ey module B. If incorrect, then an "Incorrect Amount" 
message is sent. (Steps 612 - 616). In the event of an 
"Incorrect Amount" message, money module B informs 
money module A which, in tum, requests its trusted 
. agent to resend a new amount or else atxxt (steps 61 8 
- 622, 572 - 582). In money module payments made dur- 
ing an electronic merchandise purchase, the trusted 
agent wilt not send a new amount and hence both noon- 
ey modules 6 and both trusted agents 120 will aix>rt. 
[0127] If. on the other hand, money nrKxiule B receives 
a "Correct Amount" message from its trusted agent, 
then money module B sends an Acknowledgement 
message back to the customer's money module (steps 
624 - 626). When MM Pay/Exchange A receives the Ac- 
knowledgement message, it then passes the arTK>unt to 
Money Holder A (the applicatkxi whrch contains and 
manages the electronic representatkxis of money) (step 
628). 

[0128] Note that the payor initiated protocol just de- 
scribed may instead be implemented as a payee initiat- 
ed payment as in the POS Payment protocol. In such a 
protocol, the merchant's trusted agent instructs its rDon- 
ey module as to the payment amount it expects to re- 
ceive, this payment informatksn is sent to the customer's 
money module which prompts its trusted agent for ver- 
ification, and if the arrK>unt is correct, then the custom- 
er's trusted agent informs its money module. 
[0129] Referring again to Figure 12, the custonrrar*s 
money module A then transfers electronic notes in the 
amount specified to the merchant's money module 4 via 
the E-Routed message path (step 630). Figure 20 
shows a Transfer Notes protocol as described in WO- 
A-96/33476. Note Directory X chooses the note(s) and 
values for transfer, updates the note amount(s) and se- 
quence numt>er(s), and then sends the message to 
Notes (step 1566). Possble objectives in choosing the 
notes for transfer may, for example, be: (1 ) minimize the 
numk>er of digital signatures (which requires processing 
tifTYe); (2) minimize the size of the packet; (3) maximize 
the usefulness of the electronb notes left to the trans- 
ferring subscriber (i.e., pass the rK»tes with the shortest 
time left until expiration). Such objectives may be 
achieved by the following note transfer algorithm: (1 ) de- 
termine all possible alternatives whk:h contain the least 
number of notes; (2) determine which of these alterna- 
tives have the least number of transfers; (3) if more than 
one choice is left from step 2, choose the one which has 
the least number of monetary unit days. Monetary-unit 
days = residual value of riote to be transferred times the 
number d days left until the note expires, summed for 
all the notes in the packet. 

[O130| Notes X, upon receiving the message from 
Note Directory X, creates a transfer to be appended to 
each note being transferred (step 1568). Public Key X 



creates signatures for the note(s) (step 1570). Packet 
Manager X then assembles the note(s) with their new 
transfer(s) and signature(s) in a packet and sends the 
packet to Y (steps 1572 - 1574). Packet Manager Y re- 
s ceives the packet and disassembles it (step 1576). 
[0131] Verify Y validates all certificates in the note(s) 
(e.g., money generator certificate and all transfer certif- 
icates). Then Verify Y verifies that the identification num- 
bers in the transfer group match up with the module 
identification numbers of tiie certificates in the signature 
and certificate group throughout the history of the elec- 
tronic note. Also, the consistency of the transfer 
amounts for each note is validated by ensuring that 
throughout the electronic note history the amount trans- 
ferred in each successive transfer is less than that of the 
immediately precedent transfer. In additbn, the total 
amount transferred is checked to ensure it is the amount 
expected. (Steps 1578 - 1580). If not valid, then the 
transaction is aborted (step 1582). 
[0132] If valid and Y is a transaction money nrKxiule, 
then Veritier Y verifies the expiratk)n dates of the note 
(s) (steps 1584 - 1588). If any of the note(s) have ex- 
pired, then the transaction is aborted. If none have ex- 
pired, then Verifier Y checks.each id from the note trans- 
fers against the bad id list (steps 1590 - 1592). If any of 
the transfer id's are on the bad id list, then the transac- 
tion is akx)rted. 

[0133] If the transfer id's are not on the bad id list (or 

Y is not a transaction money module), then Public Key 

Y verifies the validity of the note(s) signatures (steps 
1594 - 1596). If any of the signatures are not vaiki, then 
the transaction is aborted. If the signatures are valid, 
then Verifier Y checks if the note(s) bodies match note 
bodies that are stored by the Notes applicatk>n or locat- 
ed in the Tran Log (steps 1598 - 1600). For each note 
body that matches, a ncAe transfer tree is created in or- 
der to determine whether there has k>een any note du- 
plk^tkxi (steps 1602 - 1604). If any of the notes have 
been duplicated, then the transaction is aborted. This 
check for duplication (i.e., steps 1598-1604) is particu- 
larly directed to. and well suited for. thwarting individuals 
who attempt to create money by transferring notes by 
"self-dealing" using a compromised transactbn money 
module. 

[0134] If there are no duplicates, or if no matches of 
note bodies were kientified, then Notes Y places the 
note(s) in the money hokJer (step 1606). Finally, Note 
Directory Y updates the note(s) location(s) and amount 
(s). and also initializes sequence number(s) (step 1 608). 
[0135] It may be understood that the Transfer Notes 
process includes steps for updating and initializing a se- 
quence number to facilitate note reconciliatkwi, check- 
ing if the transferee of any note is on the bad id list, and 
checking for note duplk:ation. These additional features 
arKl steps make it difficult for adversaries to introduce 
and circulate duplicated notes, and enhance the ability 
to detect duptk:ated notes in circulatkxi. 
[0136] Referring back to Figure 12, a MM Commit 
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subroutine is called (step 632). A Commit protocol as 
used in the preferred electronic monetary system is de- 
scribed in WO-A-96/33476 and shown in Figure 21. 
Session Manager X sends a ■Ready4o-Commif mes- 
sage to Y (steps 1702 - 1704). This passes the obliga- 
tion to commit to the module receiving the message. In 
a conventional money transfer scenario, this technique 
of passing the burden of committing first Is used to en- 
sure that the party transferring money commrts first, so 
as to eliminate the possibility dt duplicating money. 
[0137] Session Manager Y then sends an acknowl- 
edgment to X (steps 1706 - 1708) and commits to any 
outstanding transactions by updating its transaction log 
(step 1710). Also, if Y is a trar^saction money module, 
then To subscriber Y rK>trfies the subscriber of the suc- 
cessful transaiction (steps 1712 - 1714). Session Man- 
ager Y notes the end of the session (step 1716). 
[0138] Tran Log X receives the acknowledgement 
from Y and updates its transaction log, thus committing 
to any outstanding transfers. X completes its commit in 
the same manner as Y (steps 1718 - 1724). 
[0139] Ttiis ftow diagram is still folbwed when nnoney 
modules 6 are interacting with trusted agents 120 with 
the understanding that Send Message = Send E-Routed 
Message and that To Subscriber messages are actually 
sent encrypted to the trusted agent 120. With the fore- 
going in mind, rDoney module B's MM Session Mar^ger 
sends a ■Ready-To-Commit' message to money module 
A's MM Session Manager via the send E-Routed Mes- 
sage subroutine (steps 1702 - 1704). MM Session Man- 
ager A then sends an 'Acknowledgement' message to 
nfK>ney module B and nrioney module A commits (steps 
1706 - 1716). When money module B receives the 'Ac- 
knowledgement" message rt too commits (steps 1718 - 
1724). 

[0140] During the cormiit routines of money modules 
A and B, they generate messages sent to their trusted 
agents A an6 B, respectively (steps 171 4, 1722) inform- 
ing them that they have committed to the transaction 
and hence that the payment was successful. 
[0141] Referring again to Fipure 12. the money mod- 
ules then both send the aforementkxied 'Payment Suc- 
cessful* messages to their trusted agents (steps 584 - 
586). These messages are encrypted by session key 
(TA/MM). Sesskxi Manager A detects that a successful 
payment has been made and Ticket Hokier A updates 
the receipt ticket with payment informatkxi such as the 
date of transaction (steps 588, 592, 634). Trusted agent 
A then commits (step 636) so that its retention of the 
ticket is no kxiger 'provisbnal'. Similarly, Session Man- 
ager B detects a successful payment (steps 590, 594) 
and trusted agent B commits (step 638). The transaction 
Is now complete. 

[0142] Referring back to Figure 7, the prevous dis- 
cussion described the situation where a customer 
wished to sell electronic rTK)ney to a merchant in ex- 
change for a debit to his bank account. In the case where 
the customer wants to receive electronk; money from 



the merchant, Purchase B queries the money module 
for sufficient funds (steps 724 - 726). If the money mod- 
ule within the MTD has insufficient funds, then To Host 
B requests guidance from the host which checks if other 
5 of the merchant's transaction devices have the request- 
ed amount (steps 728 - 732). If yes, then Host B sends 
a message to this other transaction device (having a 
Host C) to send money (step 734). A sessk)n is estab- 
lished between C and B and a money module payment 
is made (steps 736 - 738). It may be noted that in this 
scenarb there Is no ticket as Indicated in step 634 of the 
money module payment. This step may simply be 
skipped under this circumstance. 
[01 43] If no other MTD has sufficient funds, then Host 
B checks If it can withdraw the amount from a bank 
where it has an account (steps 740 - 742). If so, then 
money rtKxiule A withdraws electronic money from the 
bank (step 748) using the money generator module 202, 
teller module 204, and banking system 206, as de- 
scribed in WO-A-93/10503. If no electronic money can 
be withdrawn, then IHost B requests an abort, and the 
transactkxi is aborted (steps 744 - 746). 
[0144] At the point where the merchant has sufficient 
funds to distribute to the customer, the transaction pro- 
ceeds as described In steps 750 - 794. To Host B then 
sends a message with the amount and credential to the 
card authorizatton network 208, to debit the bank ac- 
count kientified by the credential (step 810). The card 
authorizatkxi process proceeds (step 811) and Pur- 
chase B checks if the debit has been authorized (steps 
813 - 815). If not authorized, then the transaction is 
aborted, otherwise trusted agent B makes a money 
nrKxJule payment to trusted agent A completing the 
transactbn (step 817). 



Claims 

1 . A system for the open distributk>n of electronic mon- 
ey comprising: 

a customer trusted agent unit (2); 
a first money module associated with sakj cus- 
tomer trusted agent unit that securely commu- 
ncates with saki customer trusted agent unit; 
a merchant trusted agent unit (4) that establish- 
es a first cryptographbally secure session with 
sakj customer trusted agent unit; 
a second money module associated with said 
merchant trusted agent unit that securely com- 
municates with said merchant trusted agent 
unit, and that establishes a second crypto- 
graphicalty secure sesskxi with sakJ first money 
module; 

where said customer trusted agent unit (2) pro- 
vides electrons money purchase information 
and an account credential to saki merchant 
trusted agent unit (4), and sakJ merchant trust- 
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ed agent unit provides a receipt ticket (8) to said 
customer trusted agent unit; 
where said merchant trusted agent unit access- 
es an authorization network and initiates an au- 
thorizatk)n process using information from said 
electronic money purchase information and 
said account credential; 
where upon receiving authorization, said mer- 
chant trusted agent unit initiates a transfer of 
electronic money from said second rTK)ney 
module to said first money module. 

2. The system of claim 1 , wherein saki account cre- 
dential is a credit or debit card tcket. 

3. The system of claim 1 , wherein sakJ customer trust- 
ed agent unit also provkies electronk: money sate 
informatkxi to said merchant trusted agent unit, 
whk:h uses information from said electrons money 
sale information and saki account credential in an 
authorizatbn process, where upon receiving au- 
thorizaton said merchant trusted agent unit initiates 
a protocol where said first money module transfers 
electronic money to sakl second money module. 

4. The system of claim 1 , where sakl merchant trusted 
agent unit nnitiates the transfer of electronc money 
to sakl second money module from another com- 
monly owned money nrxxlule, and where saki elec- 
tronc money from said another money nrxxiule is 
distributed to said first money module. 

5. The system of claim 1 , wherein saki second money 
module accesses a bank network of a bank provid- 
ing electronic money, and withdraws electronk: 
rnoney from saki bank for distributk)n to said first 
money nrKxiule. 

6. The system of claim 1 , wherein saki receipt tk^ket 
(8) includes said customer's bank ID, account 
number and authorizatkxi amount. 

7. A system for the open distribution of electronk: mon- 
ey comprising: 

a customer trusted agent unit (2); 
a first money module associated with said cus- 
tonrter trusted agent unit that securely commu- 
nicates with said customer trusted agent unit; 
a merchant trusted agent unit (4) that establish- 
es a first cryptographicalty secure sessk)n with 
said customer trusted agent unit; 
a second money module associated with saki 
merchant trusted agent unit that securely com- 
municates with saki merchant trusted agent 
unit, and that establishes a second crypto- 
graphically secure session with saki first money 
module; 



where said customer trusted agent unit pro- 
vides electronic money sale infomnation and an 
account credential to said merchant trusted 
agent unit, and saki merchant trusted agent unit 
5 provides a receipt ticket (8) to saki customer 

trusted agent unit; 

where said merchant trusted agent unit access- 
es an authorization network and initiates an au- 
thorization process using lnformatk)n from saki 
10 electronic money sale information and said ac- 

count credential; 

where upon receiving authorization, said cus- 
tomer trusted agent unit initiates a transfer of 
electronk: money from said first money nrxxiule 
^5 to saki second money module. 

8. The system of claim 7, wherein said account cre- 
dential Is a credit or debit card ticket. 

20 9. The system of claim 7, wherein said receipt ticket 
includes said customer's bank ID, account number, 
and authorization amount. 

10. A method for open distribution of electronk: money 
25 utilizing a customer toisted agent unit, a first money 
module, a merchant trusted agent unit, and a sec- 
ond money nrxxiule. comprising the steps of: 

(a) establishing a first cryptographically secure 
30 session between saki customer trusted agent 

unit and said merchant trusted agent unit; 

(b) said customer trusted agent unit transfer- 
ring electrons money purchase information 
and an account credential, via said first crypto- 

35 graph k:ally secure session, to said merchant 

trusted agent unit; 

(c) saki merchant trusted agent unit creating a 
receipt ticket including, at least in part, saki 
electronic money purchase information and 

40 saki customer's bank account number; 

(d) saki merchant trusted agent unit transfer- 
ring saki receipt ticket, via said first crypto- 
graphk:ally secure sessbn, to said customer 
trusted agent unit whk:h provisk)nally retains 

45 saki tk:ket; 

(e) saki merchant trusted agent unit accessing 
an authorization network and initiating an au- 
thorizatkxi process using informatbn from saki 
electronic money purchase information and 

50 saki account credential; 

(f) establishing a second cryptographicalty se- 
cure session between said first money module 
and said second money nrxxiute; 

(g) said second money module transferring 
55 electron k: money, via said second cryptograph- 

k:alty secure session, to said first money mod- 
ule which provisionally retains saki electronk: 
nnoney; 
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(h) said first money module ccmmitting, where- 
upon said retention of said electronb rrx)ney is 
no longer provisional, and securely informing 
said customer trusted agent unit of successful 
electronic money receipt; s 

(i) said second money module committing, and 
securely informing said merchant trusted agent 
unit of successful electronic money transfer; 
(j) said customer trusted agent unit committing, 
whereupon said retention of said receipt ticket 
is no longer provisional; arKi 
(k) said merchant trusted agent unit commit- 
ting. 



11. The method of claim 10, wherein saki account cre- 
dential is a credit or debit card tbket having said 
customer's bank account number. 

12. The method of claim 10, further including the step 
of said customer trusted agent unit verifying said re- 
ceipt tbket. 

13. A method for open distributkxi of electronic money 
utilizing a customer trusted agent unit, a first money 
module, a merchant trusted agent unit, and a sec- 
ond money module, comprising the steps of: 

(a) establishing a first cryptographk^lty secure 
session between sakJ customer trusted agent 
unit and saki merchant trusted agent unit; 

(b) saki customer trusted agent unit transfer- 
ring electron c money sale infomiatnn arKi an 
account credential, via saki first cryptographi- 
cally secure session, to sakj merchant trusted 
agent unit; 

(c) said merchant trusted agent unit creating a 
receipt ticket including, at least in part, saki 
electronk: money sale informatkxi and saki 
customer's bank account number; 

(d) saki merchant trusted agent unit transfer- 
ring said receipt tcket. via saki first crypto- 
graphically secure session, to saki customer 
tmsted agent unit whk^h prcviskyialty retains 
saki tbket; 

(e) saki merchant trusted agent unit accessing 
an authorizatkxi network and onrtiatirtg an au- 
thorizatkxi process using information from said 
electrons money sale informatkxi arKi said ac- 
count credential; 

(f) establishing a second cryptographically se- 
cure sessk>n between saki first rrKxiey module 
arKi saki second money module; 

(g) saki first money module transferring elec- 
tronk: money, via saki second cryptographk:ally 
secure sesskxi. to saki second money rrxxiule 
which provisionally retains saki electronk: mon- 
ey; 

(h) saki first money module committing and se- 



curely infonning said customer trusted agent 
unit of successful electronk: money transfer; 
(i) said second money nruxiule committing, 
whereupon said retention of said electronk: 
money is no longer provisional, and securely in- 
forming said merchant trusted agent unit of suc- 
cessful electronic money receipt; 
(j) said customer trusted agent unit committing, 
whereupon saki retentkxi of said receipt ticket 
is no longer provistonal; and 
(k) saki merchant trusted agent unit commit- 
ting. 

14. The method of claim 13, wherein said account cre- 
dential is a debit or credit card ticket having saki 
customer's bank account number. 

15. The method of claim 13, further including the step 
of saki customer trusted agent unit verifying said re- 

20 ceipt ticket. 

16. A system for the secure distribution of electronk: 
rTKXiey comprising: 

2S a tamper-proof first electronic transaction de- 

vice including a first processor; 
a tamper-proof second electronic transaction 
devk:e including a second processor and that 
communk:ates with said first electrons trans- 
it) action device via a cryptographk:alty secure 
session; 

where saki first processor is adapted to transfer 
electronic money purchase amount information 
and a customer account credential to saki s^- 

35 ond electronic transactktn devbe; 

where saki second processor incorporates saki 
electronk: money purchase amount information 
and informatkxi from saki customer account 
credential in a receipt tk:ket and transfers saki 

^ receipt ticket, via said cryptographk:ally secure 

session, to saki first electronk: transactkxi de- 
vice; 

where said second processor initiates an au- 
thorization process based on said electronic 
45 money purchase amount information and infor- 

matkxi from saki customer account credential; 
and 

where, in the event authorization is received, 
saki second electronic transaction device 
50 transfers electronic money to saki first electron- 

k: transaction devk:e, thereby provkiing for the 
distributkxi of electronk: money independent of 
whether a customer's bank distributes electron- 
k: money. 

55 

17. The system of claim 16, whereiri saki second elec- 
tronic transaction devk:e is connected to a mer- 
chant networic and an authorizatkxi networit con- 
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nected to a customer's bank network; where said 
authorizatksn process is executed over sakl author- 
ization network. 

18. The system of claim 1 7, wherein said second elec- s 
tronb transactbn device is connected to a mer- 
chant's bank network of a bank that distributes elec- 
trons money. 

1 9. The system of claim 1 6, wherein said customer ac- io 
count credential is a debit or credit card tk:ket hav- 
ing said customer's bank account number. 

20. A system for the secure distributk)n of electronic 
money comprising: is 

a tamper-proof first electronk; transaction de- 
vice Including a first processor; 
a tamper-proof second electronk: transactkxi 
device including a second processor and that 20 
communrcates with saki first electronic trans- 
actKNTi devbe via a cryptographk:al}y secure 
session; 

where said first processor is adapted to transfer 
electronk: money sale information and a cus- ^5 
tomer account credential to sakl second elec- 
tronic transact bn devk:e; 
where said second processor incorporates said 
electronk: money sale information and informa- 
tk>n from said customer account credential in a 30 
receipt XtckeX arxJ transfers saki resetpt ticket, 
via sakJ cryptographically secure session, to 
said first electronic transaction devbe; 
where sakt second processor initiates an au- 
thorizdtk>n process based on sakJ electronic 35 
nrx>ney sale infonmation and informatk>n from 
said customer account credential; arKt 
where, in the event authorizatk»n ts received, 
said first electronic transaction devk^e transfers 
electronk: money to said secorid electronic 40 
transactkxi devk:e. 

21. The system of claim 20, wherein said second elec- 
tronk; transactbn devrce is connected to a mer- 
chant network and an authorization network con- 4S 
nected to a customer's bank network; where said 
authorizatk)n process is executed over sakJ author- 
ization network. 

22. The system of claim 21 , wherein said second elec- so 
tronk: transaction device is connected to a mer- 
chant's bank network of a bank that distributes elec- 
trons: nrxxiey. 

23. The system of claim 20, wherein sakJ customer ac- ss 
count credential is a debit or credit card tk:ket hav- 
ing said customer's bank account number. 



Patentanspruche 

1. System fur die offene Ausgabe von elektronischem 
Geld, umfassend: eine vertrauenswurdige Kunden- 
Agenteneinhert (2); ein genanntervertrauenswOrdi- 
ger Kunden-Agenteneinhert zugeordnetes erstes 
Geldmodul, das sicher mit genannter vertrauens- 
wurdiger Kunden-Agenteneinhelt kommuniziert; ei- 
ne vertrauenswurdige Handler-Agenteneinheit (4), 
die eine erste kryptographisch sk:here Sitzung mit 
genannter vertrauenswurdiger Kunden-Agenten- 
einheit einrichtet; ein genannter vertrauenswurdi- 
ger Handler-Agenteneinheit zugeordnetes zweites 
GeldnrKxlul. das sk:her mit genannter vertrauens- 
wurdiger Handler-Agenteneinheit kommuniziert 
und das eine zweite kryptographisch sk:here Sit- 
zung mit genanntem erstem Gekimodul einrk:htet; 
wobei genannte vertrauenswurdige Kunden-Agen- 
teneinheit der genannten vertrauenswurdigen 
Handler-Agenteneinheit Kaufinformatk)nen betref- 
fend elektronisches Geld und eine Kontobeglaubi- 
gung lief ert und wobei genannte vertrauenswurdige 
Handler-Agenteneinheit der genannten vertrauens- 
wurdigen Kunden-Agenteneinhelt eine Empfangs- 
bescheinigung (8) lief ert; wobei genannte vertrau- 
enswurdige Handler-Agenteneinheit Zugang zu ei- 
nem Berechtigungsnetz herstellt und unter Verwen- 
dung von !nformatk)nen von genannten Kaufinfor- 
matbnen betreffend elektronisches Geki und ge- 
nannter Kontobeglaubigung einen Berechtigungs- 
prozeB einleitet; wobei genannte vertrauenswurdi- 
ge Handler-Agenteneinheit bei Erhalt der 
Berechtigung einen Transfer von elektronischem 
Geld von genanntem zweitem Geldmodul zu ge- 
nanntem erstem Geldmodul einleitet. 



3. 



System nach Ar^pruch 1 , 
beglaubigung ein Kredit- 
ist. 



wobei genannte Konto- 
oder Debetkartenbeleg 



System nach Anspruch 1 , wobei genannte vertrau- 
enswurdige Kunden-Agenteneinheit der genannten 
vertrauenswurdigen Handler-Agenteneinheit auch 
Verkaufsintormationen betreffend elektronisches 
Geld liefert, die Informationen von genannten Ver- 
kaufsintormationen betreffend elektronisches Geld 
und genannter Kontobeglaubigung in einem Be- 
rechtlgungsprozeB verwendet, wobei genannte 
vertrauenswurdige Handler-Agenteneinheit bei Be- 
rechtigungserhatt ein Protokoll einleitet, wobei ge- 
nanntes erstes Geldmodul elektronisches Geld an 
genanntes zweites Gekimodul transferiert. 

System nach Anspruch 1 , wobei genannte vertrau- 
enswurdige Handler-Agenteneinheit den Transfer 
von elektronischem GeW zu genanntem zweitem 
Geldmodul von einem weiteren, in gemeinsamem 
Besitz befindlichen Geldmodul einleitet und wobei 
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genanntes elektronisches Geld von genanntem 
weiterem Geldmodul zu genanntem erstem Geld- 
modul ausgegeben wird. 

5. System nach Anspruch 1 , wobei genanntes zwertes 
Geldmodul auf ein Banknetz einer elektronisches 
Geld bereitstellenden Bank zugrerft und elektroni- 
sches Geld von der genannten Bank zur Ausgabe 
an genanntes erstes Geldmodul abhebt. 

6. System nach Anspruch 1. wobei genannte Emp- 
fangsbeschelnigung (8) die Bankleftzahl, die Kon- 
tonummer und den Berechtigungsbetrag des ge- 
nannten Kunden aufwetst. 

7. System fur die offene Ausgabe von elektronischem 
GeM, umfassend: eine vertrauenswurdige Kunden- 
Agenteneinheit (2); ein genannter vertrauenswurdi- 
ger Kunden-Agenteneinheit zugeordnetes erstes 
Geldmodul, das sicher mit genannter vertrauens- 
wurdiger Kunden-Agenteneinheit kommuniziert; ei- 
ne vertrauenswOrdige Handler-Agenteneinheit (4). 
die eine erste kryptographisch sichere Srtzung mit 
genannter vertrauenswurdiger Kunden-Agenten- 
einheit einrbhtet; ein genannter vertrauenswurdi- 
ger Handler-Agenteneinheit zugeordnetes zwertes 
Gekimodul, das sicher mit genannter vertrauens- 
wurdiger Handler-Agenteneinheit kommuniziert 
und das eine zwerte kryptographisch srchere Srt- 
zung mit genanntem erstem Gekfrnodul einrichtet; 
wobei genannte vertrauenswurdige Kunden-Agen- 
teneinhert der genannten vertrauenswurdigen 
Handler-Agenteneinheit Verkaufsinformationen be- 
treffend elektronisches Geld und eine Kontobeglau- 
bigung liefert und wobei genannte vertrauenswur- 
dige Handler-Agenteneinheit der genannten ver- 
trauenswurdigen Kunden-Agenteneinheit eine 
Emptangsbescheinigung (8) liefert; wobei genann- 
te vertrauenswOrdige Handler-Agenteneinheit auf 
ein Berechtigungsnetz zugreift urKl unter Verwen- 
dung von lnformat»nen von genannten Verkaufs- 
informatkxien betrefferKt elektron^ches Geki und 
genannter Kontobeglaubigung einen Berechti- 
gungsprozeS einleitet; wobei genannte vertrauens- 
wurdige Handler-Agenteneinheit bei Erhatt der Be- 
rechtigung einen Transfer von elektronischem GekJ 
von genanntem erstem GekJmodul zu genanntem 
zweitem Geldmodul einleitet. 

8. System nach Anspruch 7, wobei genannte Konto- 
beglaubigung ein Kredit- oder Debetkarteribeleg 
ist. 

9. System nach Anspruch 7. wobei genannte Emp- 
fangsbescheinigung (8) die Bankleitzaht, die Kon- 
tonummer und den Berechtigungsbetrag des ge- 
nannten Kunden aufweist. 



10. Verfahren zur offenen Ausgabe von elektronischem 
Geld unter Verwendung einer vertrauenswurdigen 
Kunden-Agenteneinheit, eines ersten GekJmoduts, 
einer vertrauenswurdigen Handler-Agenteneinheit 

s und eines zweiten Gekimoduls. das folgende 
Schritte umfaBt: (a) Einrichten einer ersten krypto- 
graphisch sicheren Sitzung zwischen genannter 
vertrauenswurdiger Kunden-Agenteneinhert und 
genannter vertrauenswurdiger Handler-Agenten- 

10 einheit; (b) Transfer von Kaufinformationen betref- 
fend elektronisches Geld und eine Kontobeglaubi- 
gung von der vertrauenswurdigen Kunden-Agen- 
teneinheit uber genannte erste kryptographisch si- 
chere Sitzung zu genannter vertrauenswurdiger 

IS Handler-Agenteneinheit; (c) Erstelten einer Emp- 
tangsbescheinigung durch genannte vertrauens- 
wurdige Handler-Agenteneinheit, die, wenigstens 
teilweise, genannte Verkaufsinformationen betref- 
fend elektronisches GekJ und genannte Bankkon- 

20 tonummer des Kunden aufweist; (d) Transfer der 
genannten Emptangsbescheinigung durch ge- 
nannte vertrauenswurdige Handler-Agenteneinheit 
uber genannte erste kryptographisch srchere Sit- 
zung zu genannter vertrauenswurdiger Kunden- 

2S Agenteneinheit, die genannte Bescheinigung vor- 
laufig einbehatt; (e) Zugang zu einem Berechti- 
gungsnetz und Einleiten eines Berechtigungspro- 
zesses durch genannte vertrauenswOrdige Hand- 
ler-Agenteneinheit unter Verwendung von genann- 

30 ten Kaufinformationen betreffend elektronisches 
Geld und genannter Kontobeglaubigung; (f) Ein- 
richten einer zweiten kryptographisch sicheren Sit- 
zung zwischen genanntem erstem Geldmodul und 
genanntem zweitem Geldmodul; (g) Transfer von 

3S elektronischem Geld durch genanntes zweites 
GeldrTK>dul uber genannte zweite kryptographisch 
sk:here Sitzung zu genanntem erstem Geklmodul, 
das genanntes elektronisches Geld vorlaufig einbe- 
halt; (h) Zusage des genannten ersten Gekimoduls, 

^ woraufhin genanntes Einbehalten genannten elek- 
tronischen Gekles nicht mehr vorlaufig ist, und si- 
cheres tnformieren der genannten vertrauenswOr- 
digen Kunden-Agenteneinheit uber den erfolgrei- 
chen Erhatt von elektronischem Geld; (i) Zusage 

45 des genannten zweiten Geldmoduls und sicheres 
Informieren der genannten vertrauenswurdigen 
Handler-Agenteneinheit uber den erfolgreichen 
Transfer von elektronischem Geld; (j) Zusage der 
genannten vertrauenswOrdigen Kunden-Agenten- 

50 einheit, woraufhin genanntes Einbehalten genann- 
ter Emptangsbescheinigung nicht mehr vorlaufig 
ist, und (k) Zusage der genannten vertrauenswOr- 
digen Handler-Agenteneinheit. 

ss 11, Verfahren nach Anspruch 10, wobei genannte Kon- 
tobeglaubigung ein Kredit- oder Debetkartenbeleg 
mit der Bankkontonummer des genannten Kunden 
ist. 
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12. Verfahren nach Anspruch 1 0, das des weiteren den 
Schrrtt der Nachprufung genannter Empfangsbe- 
scheinigung durch genannte vertrauenswurdige 
Kunden-Agenteneinhett aufweist. 

1 3. Verfahren zur offenen Ausgabe von elektronischem 
Geld unter Verwendung einer vertrauenswurdigen 
Kunden-Agenteneinheit, eines ersten Geldmoduls. 
einer vertrauenswurdigen Handler-Agenteneinheit 
und eines zweiten Geldmoduls, das folgende 
Schritte umfaBt: (a) Einrlchten einer ersten krypto- 
graphisch sicheren Sitzung zwischen genannter 
vertrauenswurdlger KurKien-Agenteneinheit und 
genannter vertrauenswurdiger Handler-Agenten- 
einheit; (b) Transfer von Verkaufsinformatwnen be- 
treffend elektronisches GekJ und einer Kontobe- 
glaubigung von genannter vertrauenswurdiger 
Kunden-Agenteneinheit uber genannte erste kryp- 
tographisch sichere Sitzung zu genannter vertrau- 
enswurdiger Handler-Agenteneinheit; (c) Erstellen 
einer Empfangsbescheinigung durch genannte ver- 
trauenswurdige Handler-Agenteneinheit, die. we- 
nigstens teilweise. genannte VerkaufsinfomDatb- 
nen betreffend elektronisches Geld und Bankkon- 
tonummer des genannten Kunden aufweist; (d) 
Trartsfer genannter Empfangsbescheinigung durch 
genannte vertrauenswOrdige HarYdler-Agentenetn- 
heit uber genannte erste kryptographisch sichere 
Sitzung zu genannter vertrauenswurdiger Kuruien- 
Agenteneinhert, die genannte Bescheinigung vor- 
laufig etnbehalt; (e) Zugang zu einem Berechti- 
gungsnetz und Einleiten eines Berechtigungspro- 
zesses durch genannte vertrauenswurdige Hand- 
ler-Agenteneinheit unter Venvendung von genann- 
ten Kaufinformatk>nen betreffend elektronisches 
Gekl urKl genannter Kontobeglaubigung; (f) Ein- 
rk:hten einer zweiten kryptographisch sicheren Sit- 
zung zwischen genanntem erstem Geldmodul urKi 
genanntem zweitem Gektrrxxlul; (g) Transfer von 
elektronischem Geki durch genanrvtes zwettes 
Geldmodul uber genannte zweite kryptographisch 
sichere Sitzung zu genanntem erstem Geldmodul, 
das genanntes elektronisches Geki vortaufig einbe- 
hatt; (h) Zusage des genannten ersten Geldmoduls 
ur\6 sicheres Infonmieren der genannten vertrau- 
enswurdigen Kunden-Agenteneinheit uber den er- 
folgreichen Transfer von elektronischem GekJ; (i) 
Zusage des genannten zweiten Gekimoduls, wor- 
aufhin genanntes Einbehalten genannten elektroni- 
schen Geldes nicht mehr vortaufig ist, und sk:heres 
Infonmieren der genannten vertrauenswurdigen 
Handler-Agenteneinheit uber den erfolgrek:hen Er- 
hatt von elektronischem Geld; (j) Zusage der ge- 
nannten vertrauenswurdigen Kunden-Agentenein- 
heit, woraufhin genanntes Einbehalten genannter 
Empfangsbescheinigung nk:ht mehr vortaufig ist, 
und (k) Zusage der genannten vertrauenswurdigen 
Handler-Agenteneinheit. 



14. Verfahren nach Anspruch 13, wobei genannte Kon- 
tobeglaubigung ein Kredit- Oder Debet kartenbeleg 
mit der Bankkontonummer des genannten Kunden 
ist. 

5 

15. Verfahren nach Anspruch 1 3, das des weiteren den 
Schritt der Nachprufung genannter Empfangsbe- 
scheinigung durch genannte vertrauenswurdige 
Kunden-Agenteneinheit aufweist. 

10 

16. System fOr die sichere Ausgabe von elektroni- 
schem Geld, umfassend: eine unverletzliche erste 
elektronische Transaktbnsvorrichtung mit einem 
ersten Prozessor; eine unverletzliche zweite elek- 

*5 tronische Transaklionsvorrichtung mit einem zwei- 
ten Prozessor, die uber eine kryptographisch siche- 
re Sitzung mit genannter erster elektronischer 
Transaktk>nsvorrichtung kommuniziert; wobei ge- 
nannter erster Prozessor fur den Transfer von Kauf- 

20 betraginformationen betreffend elektronisches 
Geld und eine Kunden kontobeglaubigung zu ge- 
nannter zweiter elektronischer Transaktionsvor- 
richtung ausgefuhrt ist; wobei genannter zweiter 
Prozessor genannte Kaufbetraginformationen be- 

25 treffend elektronisches Geld und lnformatk)nen von 
genannter Kundenkontobeglaubigung in einen 
Empfangsbescheinigung einfugt und genannten 
Empfangsbescheinigung uber genannte kryptogra- 
pisch sichere Sitzung zu erster elektronischer 

30 Transaktk)nsvorrichtung transferiert; wobei ge- 
nannter zweiter Prozessor einen Berechtigungs- 
prozeB gestutzt auf genannte Kaufbetraginforma- 
tionen betreffend elektronisches Geld und Informa- 
tionen von genannter Kundenkontobeglaubigung 

3S einteitet und wobei genannte zweite elektronische 
Transaktknsvorrichtung im Fall des Ertialtens einer 
Berechtigung elektronisches Geld zu genannter er- 
ster elektronischer Transaktionsvorrichtung trans- 
feriert. wodurch fur die Ausgabe von elektroni- 

40 schem Geld unabhangig davon gesorgt wird, ob die 
Bank eines Kunden elektronisches Geki ausgibt 

17. System nach Anspruch 16, wobei genannte zweite 
elektronische Transaktkxisvorrk;htung mit einem 

45 Handlemetz und einem mit einem Banknetz eines 
Kunden verbundenen Berechtigungsnetz verbun- 
den ist, wobei genannter Berechtigungsproze3 
uber genanntes Berechtigungsnetz durchgefdhrt 
wird. 

50 

18. System nach Anspruch 17, wobei genannte zweite 
elektronische Transaktkxisvorrrchtung mit einem 
Banknetz eines Handlers einer Bank verbunden ist, 
die elektronisches Geld ausgibt. 

55 

19. System nach Anspruch 16, wobei genannte Kun- 
denkontobeglaubigung ein Debet- oder Kreditkar- 
tenbeleg mit der Bankkontonummer des genannten 
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Kunden ist. 

20. System fur die sichere Ausgabe vcxi elektroni- 
schem Geld, umfassend: eine unvertetzliche erste 
elektronische Transaktionsvorrichtung mit einem 
ersten Prozessor, eine unverietzliche zweite elek- 
tronische Transaktkxisvorrichtung mit einem zwei- 
ten Prozessor, die uber eine kryptographisch siche- 
re Sitzung mrt genannter erster elektronischer 
Trar>saklionsvorrichtung kommuniziert; wobei ge- 
nannter erster Prozessor fur den Transfer von Ver- 
kaufstnformatkxien betreffend elektronisches Geki 
und eine Kundenkontobeglaubigung zu genannter 
zwerter elektronischer Transaktkxisvorrichtung 
ausgef uhrt ist; wobei genannter zwerter Prozessor 
die genannten Verkaufsinformatk)nen betreffend 
elektronisches GekJ und Informationen von ge- 
nannter Kundenkontobeglaubigung in einen Em^ 
fangsbescheintgung einfugt und genannten Emp- 
fangsbescheinigung uber genannte kryptograpisch 
sichere Srtzung zu genannter erster elektronischer 
Transaktionsvorrichtung transferiert; wobei ge- 
nannter zweiter Prozessor einen Berechtigungs- 
prozeB gestutzt auf genannte Verkaufslnformatk)- 
nen betrefferxj elektronisches Geld urui Informatio- 
nen von genannter Kundenkontobeglaubigung ein- 
leitet und wobei genannte erste elektronische 
Transaktionsvorrichtung im Fall des Erhaltens einer 
Berechtigung elektronisches Getd zu genannter 
zweiter elektronischer Transaktk>nsvorrichtung 
transferiert. 

21. System nach Anspruch 20. wobei genannte zweite 
elektronische Transaktkxisvorrichtung mit einem 
Handlemetz und einem mit einem Banknetz eines 
Kunden verbundenen Berechtigungsnetz verbun- 
den ist, wobei genannter BerechtigungsprozeB 
uber genanntes Berechtigungsnetz durchgefuhrt 
wird. 

22. System nach Anspruch 21 . wobei genannte zweite 
elektronische Transaktkxisvorrichtung mit einem 
Banknetz eines Handlers einer Bank verbunden ist, 
die elektronisches Geld ausgibt. 

23. System nach Anspruch 20, wobet genannte Kun- 
denkontobeglaubigung ein Debet- oder Kreditkar- 
tenbeleg mitder Bankkontonummerdes genannten 
Kunden ist. 



Revendications 

1 . Syst^me de distribution libre de fonds 6lectronk)ues 
comprenant : 

une unit6 de ddpoeitaire client (2) ; 

un premier module de fonds associ6 ^ tadite 



unrtd de ddpositaire client qui communique de 
nnanr^re sOre avec tadite unit6 de d^posrtaire 
client ; 

une unit6 de d6positaire foumisseur (4) qui 6ta- 
s blit une premiere session cryptographiquement 

sOre avec iadite unite de depositaire client ; 
un deuxi^me module de fonds associ6 a Iadite 
unit6 de depositaire foumisseur qui communi- 
que de manidre sure avec Iadite unite de d6po- 
10 sitaire foumisseur, et qui etabtit une deuxidme 

session cryptographk^uement sure avec ledrt 
premier module de fonds ; 
ou iadite unit6 de ddpositaire client (2) foumit 
des informations d'achat de fonds electroni- 
cs ques et une reference de compte k Iadite unite 
de depositaire foumisseur (4), et Iadite unite de 
depositaire foumisseur foumit un ticket de re^u 
(8) k Iadite unite de depositaire client ; 
ou Iadite unite de depositaire foumisseur solli- 
20 cite un reseau d'autorisation et lance un pro- 
cessus d'autorisatkxi en utilisant des informa- 
tions tirees desdites infomnations d'achat de 
fonds eiectroniques et de Iadite reference de 
compte ; 

2S ou sur receptkxi d'une autorisation. Iadite unite 

de depositaire foumisseur lance un transfert de 
fonds eiectroniques depuis tedit deuxieme mo- 
dule de fonds vers ledit premier module de 
fonds. 

30 

2. Systeme selon la revendicatkxi 1 , dans lequel Iadite 
reference de compte est un ticket de carte de credit 
ou de debit. 

3S 3. Systeme selon la revendication 1 , dans lequel Iadite 
unite de depositaire client foumit aussi des informa- 
tkxis de vente de fonds eiectroniques k Iadite unite 
de depositaire foumisseur, qui utilise des informa- 
tions tirees desdites informatkxis de vente de fonds 
^ etectronkiues et tadite reference de compte dans 
un processus d'autorisation, ou sur reception d'une 
autorisation Iadite unite de depositaire foumisseur 
lance un protocole sekxi lequel ledit premier modu- 
le de fonds transf ere des fonds eiectroniques audit 
4S deuxieme module de fonds. 

4. Systeme selon ta revendication 1 , dans lequel Iadite 
unite de depositaire foumisseur lance le transfert 
de fonds eiectroniques vers ledit deuxieme module 
50 de fonds depuis un autre module de fonds en pro- 
priete commune, et ou lesdits fonds etectronkjues 
provenant dudit autre module de fonds sont distri- 
bues audit premier rrKxiule de fonds. 

ss 5. Systeme sekxi ta revendication 1 , dans lequel ledit 
deuxieme module de fonds sotiicrte un reseau ban- 
caire d'une banque foumissant des fonds eiectroni- 
ques, et preieve des fonds eiectroniques de Iadite 
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banque en vue de les dtstribuer audit premier mo- 
dule de foods. 

6. Syst6me selon la revendication 1 , dans lequel ledFt 
ticket de regu (8) comporte I'identit^ bancaire , le 
num6ro de compte et la quantity autorlsee du client. 

7. Syst^me de distribution libre de fonds Electron iques 
comprenant : 

une unit6 de d§positaire client (2) ; 
un premier rruxiule de fonds associ^ k tadite 
unit6 de ddpositaire client qui communique de 
mani^re prot6g6e avec ladite unit6 de d^posi- 
taire client ; 

une unit6 de d^positaire foumisseur (4) qui 6ta- 
blit une premiere session cryptographiquement 
sOre avec tadite unit6 de d6positaire client ; 
un deuxi^me module de fonds assode ^ ladite 
units de dSpositaire foumisseur qui communi- 
que de mani^re protege avec ladite unit6 de 
dSpositaire foumisseur, et qui Stablit une 
deuxi&me session cryptographiquement sOre 
avec ledit premier module de fonds ; 
Oil ladite unit6 de d^positaire client (2) foumit 
des infomnations de vente de fonds 6lectroni- 
ques et une r6f6rence de compte k ladite unit6 
de dSpositaire foumisseur, et ladite unit6 de d6- 
positaire foumisseur foumit un ticket de regu 
(8) k ladite unit^ de dSpositaIre client ; 
ou ladite unit6 de dSpositaire foumisseur solti- 
ctte un r6seau d'autorisation et lance un pro- 
cessus d*autorisation en utilisant des informa- 
tk>ns tiroes desdites informations de vente de 
fonds ^lectronk^ues et de ladite r6f6rence de 
compte ; 

ou sur receptkyi tfune autorisatkxi, ladite unit6 
de dSpositaire client lance un transfert de fonds 
electronkiues depuis ledit premier module de 
fonds vers ledit deuxidme module de fonds. 

8. Syst^e selon la revendcatkyi 7. dans lequel ladite 
r6f 6rence de compte est un tkUcet de carte de credit 
ou de dSbit. 

9. Syst^me selon la revendk:atk)n 7, dans lequel ledit 
tk:ket de regu comporte Tidentite bancaire, le numd- 
ro de compte et la quantity autor^^ dudit client. 

1 0. Proc^dS de distributkxi libre de fonds 6lectronk)ues 
utilisant une untt6 de depositaire client, un premier 
module de fends, une units de dSpositaire foumis- 
seur, et un deuxiSme module de fonds. comprenant 
les Stapes de : 

(a) etablissement tfune premiere sesskxi cryp- 
tograph quement sDre entre ladite units de dS- 
positaire client et ladite units de dSpositaire 



foumisseur ; 

(b) ladite units de dSpositaire client transfSrant 
des informatbns d'achat de fonds Slectroni- 
ques et une rSfSrence de compte, par I'intermS- 

^ diaire de ladite premiSre session cryptographi- 

quement sOre, k ladite unitS de dSpositaire 
foumisseur ; 

(c) ladite units de dSpositaire foumisseur 
crSant un ticket de regu comportant, au moins 

10 en partie, lesdites infonnations d'achat de 

fonds Slectroniques et ledit numSro de compte 
bancaire du client ; 

(d) ladite units de dSpositaire foumisseur trans- 
fSrant ledit ticket de regu, par TintermSdiaire de 

1^ ladite premiSre sesskxi cryptographiquement 

sOre. k ladite units de dSpositaire client qui con- 
serve temporairement ledit ticket ; 

(e) ladite units de dSpositaire foumisseur solli- 
citant un rSseau d'autorisatbn et langant un 

20 processus d'autorisation en utilisant des infor- 

matksns tirSes desdites informations d'achat de 
fonds Slectroniques et de ladrte rSfSrence de 
compte ; 

(f) Stablissement d'une deuxiSme sessbn cryp- 
ts tographiquement sure entre ledit premier rro- 

dule de fonds et ledit deuxiSme module de 
fonds ; 

(g) ledit deuxiSme module de fonds transfSrant 
des fonds Slectroniques, par I'intermSdiaire de 

30 ladrte deuxiSme sessbn cryptographiquement 

sOre, audit premier module de fonds qui con- 
serve provisoirement lesdits fonds 
Slectronques ; 

(h) ledit premier module de fonds engageant 
35 les fonds, sur quoi ladrte conservation desdits 

fonds Slectroniques n'est plus provisoire, et in- 
fornDant de maniSre sOre ladite units de dSpo- 
sitaire client de la bonne rSceptkxi des fonds 
Slectronk^ues ; 

fo (i) ledit deuxiSme rrxxiule de fonds engageant 

les fonds, et informant de maniSre sure ladite 
units de dSpositaire foumisseur du transfert 
rSussi des fonds Slectroniques ; 

(i) ladite units de dSpositaire client engageant 
45 les fonds, sur quoi ladite consen/atbn dudit tic- 
ket de regu n'est plus provisoire ; et 

(k) ladite unitS de dSpositaire foumisseur enga- 
geant les fonds. 

50 11. ProcSdS selon la revendication 10, dans lequel la- 
dite rSfSrence de compte est un trcket de carte de 
crSdit ou de dSbit comportant ledit numSro de 
compte bancaire du client. 

55 12. ProcSdS selon la revendk:ation 10, comportant en 
outre fetape de vSrrfication par ladite units de dS- 
positaire client dudit X'tckeX de regu. 
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13. Proc6de de distribution libre de fonds Electron iques 
utilisant une unrt6 de dSposrtaire client, un premier 
module de fonds, une unit6 de depositaire fournis- 
seur. et un deuxi^me module defends, comprenant 
les stapes de : 

(a) etablissement d'une premiere session cryp>- 
tographiquement sOre entre ladite unit6 de de- 
positaire client et tadrte unite de depositaire 
foumisseur ; 

(b) ladite unit6 de depositaire client transf^rant 
des informations de vente de forKis 6lectroni- 
ques et une reference de compte, par finterm^- 
diaire de tadite premiere session cryptograph i- 
quement sure, k tadite unite de depositaire 
foumisseur ; 

(c) ladite unite de depositaire foumisseur 
creant un ticket de regu comportant, au nrK)ins 
en partie. lesdites informations de vente de 
foncte eiectroniques et ledit numero de compte 
bancaire du client ; 

(d) ladite unite de depositaire foumisseur trans- 
ferant ledit ticket de regu, par f intemnediaire de 
ladite premiere session cryptographiquement 
sure, k tadite unite de depositaire client qui con- 
serve temporairement ledit ticket ; 

(e) ladite unite de depositaire foumisseur solli- 
crtant un reseau d'autorisation et langant un 
processus d'autorisatk>n en utilisant des infor- 
mations tirees desdites infonmatkxis de vente 
de foTKis eiectroniques et de tadite reference 
de compte ; 

(f ) etablissement d'une deuxieme session cryp- 
tograph quement sure entre ledit premier mo- 
dule de fonds et ledit deuxieme nrxxjule de 
fonds ; 

(g) ledit premier module de forKjs trartsterant 
des fonds etectronk^ues. par rintermediaire de 
ladite deuxidme session cryptographk^uement 
sure, audit deuxieme module de fonds qui con- 
sen^e prcvisoirement lesdits foruis 
eiectronk^ues ; 

(h) ledit premier module de fonds engageant 
les fonds et informant de maniere sure ladite 
unite de depositaire client du transfert reussi 
des fonds eiectronk^ues ; 

(i) ledit deuxieme rruxiule de fonds engageant 
les fonds, sur quoi ladite consenfatk)n desdits 
forrds eiectronk|ues n'est plus provisotre, et in- 
formant de maniere sure ladite unite de depo- 
sitaire foumisseur de la bonne receptkxi des 
fonds eiectroniques ; 

(j) ladite unite de depositaire client engageant 
les fOTKis, sur quoi tadite cortsen^tkxi dudit tb- 
ket de regu n'est plus provisoire ; et 
(k) ladite unite de depositaire foumisseur enga- 
geant les fonds. 



14. Precede selon la revendication 13, dans lequel la- 
dite reference de compte est un ticket de carte de 
debit ou de credit comportant ledit numero de 
compte bancaire du client. 

5 

15. Procede selon la revendication 13, comportant en 
outre i'etape de verification par ladite unite de de- 
positaire client dudit ticket de regu. 

10 16. Systeme de distribution sOre de fonds eiectroni- 
ques comprenant : 

un premier dispositif de transaction eiectroni- 
que infraudable comportant un premier 
processeur ; 

un deuxieme dispositif de transactbn eiectro- 
nk^ue infraudable comportant un deuxieme 
processeur et qui communque avec ledit pre- 
mier dispositif de transaction electron ique par 
I'intermediaire d'une session cryptographque- 
ment sOre ; 

ou ledit premier processeur est adapte pour 
transferer des informatk>ns de quantite d'achat 
de fonds eiectroniques et une reference de 
compte client audit deuxieme dispositif de tran- 
saction eiectronique ; 

ou ledit deuxieme processeur incorpore lesdi- 
tes informations de quantite d'achat et informa- 
tions tirees de ladite reference de compte client 
dans un tk;ket de regu et transfere ledit ticket 
de regu, par I'intermediaire de ladite session 
cryptographquement sQre. audit premier dis- 
positif de transaction eiectronique ; 
ou ledit deuxieme processeur lance un proces- 
sus d'autorisation en fonction des informatbns 
de quantite d'achat de fonds electron ques et 
des informatbns tirees de tadite reference de 
compte client ; et 

ou, dans le cas ou une autorisation est regue, 
ledit deuxieme dispositif de transaction eiectro- 
nque transfere des fortds eiectroniques audit 
premier dispositif de transactbn eiectronique. 
assurant ainsi la distributk>n de fonds eiectro- 
nkjues, que la banque du client distribue ou non 
des fonds eiectronques. 

1 7. Systeme sebn la revendication 1 6, dans lequel ledit 
deuxieme dispositif de transactbn eiectronique est 
connecte au reseau d'un foumisseur et un reseau 
d'autorisatbn connecte au reseau bancaire d'un 
client ; ou ledit processus d'autorisatbn est execute 
sur ledit reseau d'autorisatbn. 

18. Systeme sebn la revendtcatbn 17, dans lequel ledit 
deuxieme dispositif de transactbn eiectronique est 
connecte au reseau bancaire d'un foumisseur 
d'une banque qui distribue des fonds eiectronques. 
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19. Systeme selon la revendication 16, dans lequet la- 
dite r^f 6rence de compte client est un ticket de carte 
de debit ou de credit comportant le num^ro de 
compte bancaire dudit client. 

5 

20. Systenie de distribution sOre de fonds electroni- 
ques comprenant : 

un premier dispositif de transaction electroni- 
que infraudable comportant un premier io 
processeur ; 

un deuxi^me dispositif de transaction 6lectro- 
nique infraudable comportant un deuxi^me 
processeur et qui communique avec ledit pre- 
mier dispositif de transaction electronique par is 
I'interm^diaire d'une session cryptographique- 
ment sure ; 

ou ledit premier processeur est adapts pour 
transferer des informations de vente de fonds 
eiectroniquesetune reference de compte client 20 
audit deuxi^e dispositif de transaction 
Electronique ; 

ou ledit deuxieme processeur irKxwpore lesdi- 
tes inforrr^tions de vente de fonds Electron i- 
ques et des informations tirEes de ladite r6fe- 2S 
rence de compte client dans un tcket de regu 
et transfEre ledit ticket de regu, par finterme- 
diaire de ladite sesskxi cryptographk^uement 
sOre, audit premier dispositif de transaction 
Electronique ; 30 
oil ledit deuxiEme processeur lance un proces- 
sus d'autortsatkxi en fonction des informations 
de vente de fortds Electrbnk^ues et des infor- 
mations tirEes de ladite rEfErence de compte 
client ; et 3S 
ou. dans le cas ou une autorisatk)n est regue. 
ledit premier dispositif de transactkxi Electroni- 
que transfEre des foTKls Electronk)ues audit 
deuxiEme dispositif de transaction Electroni- 
que. 40 

21. SystEmeseion la revendk:atkxi 20. dans lequel ledit 
deuxiEme dispositif de transactkxi Electronkfue est 
connectE au rEseau un foumisseur et un rEseau 
d'autorisation connectE au rEseau bancaire d'un 4S 
client ; ou ledit processus d'autortsation est exEcutE 
sur ledit rEseau d'autorisatkxi. 

22. Systeme selon la revendk:atk»n 21 . dar^ lequel ledit 
deuxieme dispositif de transactkxi Electronk^ue est so 
connectE au rEseau barK:aire d'un foumisseur 
d'une banque qui distribue des fonds Electronk)ues. 

23. SystEme selon la revendk^atksn 20, dans lequel la- 
dite refErerice de compte client est un tkxket de carte ss 
de dEbit ou de crEdit comportant le numEro de 
compte bancaire dudit client. 
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